Methods and systems for the sale of consumer services

ABSTRACT

Computer-implemented systems and methods for the sale of consumer services. Predictions are made based on the behaviors, preferences, assets, identifying characteristics, and other attributes associated with customers and merchants. In one implementation, a prediction is made as to whether a customer is likely to request a service and whether a merchant is likely to be selected by the customer to provide the service. In another implementation, the calendars of a merchant and customer are automatically updated to account for the customer&#39;s late arrival to an appointment at the merchants location. In yet another implementation, a customer purchases an appointment for a service from another customer that has the appointment scheduled with a merchant providing the service.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to and the benefit of U.S. provisionalpatent application No. 61/726,644, entitled “Methods, Process and Systemfor the Sale of Locally Delivered Consumer Services,” filed on Nov. 15,2012, and which is incorporated in its entirety herein.

BACKGROUND

The present disclosure relates generally to systems and methods forfacilitating a commercial transaction between a customer and a merchantand, more particularly, to systems and methods for intelligent anddynamic scheduling, monitoring, and modification of customerappointments with merchants offering locally-provided services.

In the technology- and Internet-oriented landscape of today's world,scheduling an appointment for a service should be as easy as ordering aconsumer product online. However, common life and business obstaclesthat affect scheduled services frequently arise. Some examples mayinclude late arrivals caused by a consumer's lack of familiarity withthe location of a service provider, no-shows resulting fromabsent-minded consumers, or delays in providing services arising fromoverbooking Existing approaches do little to address these problems,resulting in lost revenue, wasted time, and other inefficiencies.Accordingly, there is a need for automation and innovation in the waythat consumers purchase and consume locally-delivered consumer services.

BRIEF SUMMARY

In one aspect, a computer-implemented method comprises: predicting thata customer of a plurality of customers is likely to request a servicewherein the prediction is based on historical data comprising attributesof different customers that have previously requested the service;predicting that one or more merchants of a plurality of merchants has arespective probability of being selected by the customer to provide theservice that meets a threshold, wherein the predicting is based onhistorical data comprising attributes of different merchants that havepreviously provided the service; selecting one of the predictedmerchants based on one or more criteria; scheduling an appointment forthe service on a calendar of the customer and on a calendar of theselected merchant; and providing notification of the appointment to acustomer device of the customer and a merchant device of the selectedmerchant.

In one implementation, scheduling the appointment comprises: sendinginformation to the customer device to cause the customer device tonotify the customer of the appointment; and after sending theinformation to the customer device, receiving from the customer devicean indication of acceptance of the appointment.

In one implementation, scheduling the appointment comprises sendinginformation to the merchant device to cause the merchant device tonotify the merchant of the appointment; and after sending theinformation to the merchant device, receiving from the merchant devicean indication of acceptance of the appointment.

In one implementation, the notification is one or more of: audio,visual, and haptic.

In one implementation, predicting that the customer of the plurality ofcustomers is likely to request the service comprises: training aclassifier to predict whether a given customer would request the serviceusing the historical data comprising the attributes of differentcustomers that have requested the service; and providing attributes ofthe customer as input to the classifier and obtaining a prediction asoutput of the classifier.

In one implementation, predicting that a merchant of the plurality ofmerchants is likely to be selected by the customer comprises: training aclassifier to predict whether a given merchant would be selected toprovide the service using the historical data comprising the attributesof different merchants that have previously provided the service; andproviding attributes of the merchant as input to the classifier andobtaining a prediction as output of the classifier.

In one implementation, attributes of a particular customer comprises aplurality of the following: an identification attribute, a preferenceattribute, an asset attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:name, gender, driver's license number, social security number, no-showperformance, and home address; a particular preference attribute is oneof: level of feedback expected from merchants, type of service, whetherto automatically schedule appointments for services, whether to allowanother user to purchase an appointment, physical exercise preference,whether to follow scheduled maintenance, a preference of merchant for agiven service, and merchant location preference; a particular assetattribute is one of: primary care doctor, spouse/partner, home address,and vehicle identification number; and a particular task attribute isone of: car repair, car maintenance, doctor visit, exercise class,training, haircut, and spa appointment.

In one implementation, attributes of a particular merchant comprises aplurality of the following: an identification attribute, a preferenceattribute, a resource attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:business name, service sector, business address, gender, businesslicense, on-time performance, operating hours, type of personal careprovider, type of automotive service provider, type of buildingmaintenance provider, type of training provider, type of transportationservices provider, and type of healthcare provider; a particularpreference attribute is one of: resource utilization, accept weekendappointments, automatic appointment triage, accept emergency requests,accept insurance, and type of insurance accepted; a particular resourceattribute is one of: employee name, employee specialty, and currentlocation; and a particular task attribute is one of: car repair, carmaintenance, doctor visit, exercise class, haircut, and spa appointment.

In one implementation, a service is one of: car repair, car maintenance,doctor visit, exercise class, training, haircut, and spa appointment.

In one implementation, a particular criterion is: a distance between acurrent location of the customer device and the merchant, a customerapproval rating of the merchant, a preference of the customer, customerfeedback regarding the merchant, or a specialty of the merchant.

In one implementation, the customer device is one of: a smart phone, asmart watch, smart glasses, a portable computer, and a tablet computer.

In one implementation, the method comprises predicting that one or moreforms of a plurality of forms are likely to be required for the service,wherein the predicting is based on historical data comprising attributesof different merchants that have previously provided the service andattributes of different users that have previously requested theservice; and providing access to the predicted forms to the customer.

In another aspect, a system comprises one or more computers programmedto perform operations comprising: predicting that a customer of aplurality of customers is likely to request a service wherein theprediction is based on historical data comprising attributes ofdifferent customers that have previously requested the service;predicting that one or more merchants of a plurality of merchants has arespective probability of being selected by the customer to provide theservice that meets a threshold, wherein the predicting is based onhistorical data comprising attributes of different merchants that havepreviously provided the service; selecting one of the predictedmerchants based on one or more criteria; scheduling an appointment forthe service on a calendar of the customer and on a calendar of theselected merchant; and providing notification of the appointment to acustomer device of the customer and a merchant device of the selectedmerchant.

In one implementation, scheduling the appointment comprises: sendinginformation to the customer device to cause the customer device tonotify the customer of the appointment; and after sending theinformation to the customer device, receiving from the customer devicean indication of acceptance of the appointment.

In one implementation, scheduling the appointment comprises: sendinginformation to the merchant device to cause the merchant device tonotify the merchant of the appointment; and after sending theinformation to the merchant device, receiving from the merchant devicean indication of acceptance of the appointment.

In one implementation, the notification is one or more of: audio,visual, and haptic.

In one implementation, predicting that the customer of the plurality ofcustomers is likely to request the service comprises: training aclassifier to predict whether a given customer would request the serviceusing the historical data comprising the attributes of differentcustomers that have requested the service; and providing attributes ofthe customer as input to the classifier and obtaining a prediction asoutput of the classifier.

In one implementation, predicting that a merchant of the plurality ofmerchants is likely to be selected by the customer comprises: training aclassifier to predict whether a given merchant would be selected toprovide the service using the historical data comprising the attributesof different merchants that have previously provided the service; andproviding attributes of the merchant as input to the classifier andobtaining a prediction as output of the classifier.

In one implementation, attributes of a particular customer comprises aplurality of the following: an identification attribute, a preferenceattribute, an asset attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:name, gender, driver's license number, social security number, no-showperformance, and home address; a particular preference attribute is oneof: level of feedback expected from merchants, type of service, whetherto automatically schedule appointments for services, whether to allowanother user to purchase an appointment, physical exercise preference,whether to follow scheduled maintenance, a preference of merchant for agiven service, and merchant location preference; a particular assetattribute is one of: primary care doctor, spouse/partner, home address,and vehicle identification number; and a particular task attribute isone of: car repair, car maintenance, doctor visit, exercise class,training, haircut, and spa appointment.

In one implementation, attributes of a particular merchant comprises aplurality of the following: an identification attribute, a preferenceattribute, a resource attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:business name, service sector, business address, gender, businesslicense, on-time performance, operating hours, type of personal careprovider, type of automotive service provider, type of buildingmaintenance provider, type of training provider, type of transportationservices provider, and type of healthcare provider; a particularpreference attribute is one of: resource utilization, accept weekendappointments, automatic appointment triage, accept emergency requests,accept insurance, and type of insurance accepted; a particular resourceattribute is one of: employee name, employee specialty, and currentlocation; and a particular task attribute is one of: car repair, carmaintenance, doctor visit, exercise class, haircut, and spa appointment.

In one implementation, a service is one of: car repair, car maintenance,doctor visit, exercise class, training, haircut, and spa appointment.

In one implementation, a particular criterion is: a distance between acurrent location of the customer device and the merchant, a customerapproval rating of the merchant, a preference of the customer, customerfeedback regarding the merchant, or a specialty of the merchant.

In one implementation, the customer device is one of: a smart phone, asmart watch, smart glasses, a portable computer, and a tablet computer.

In one implementation, the operations further comprise: predicting thatone or more forms of a plurality of forms are likely to be required forthe service, wherein the predicting is based on historical datacomprising attributes of different merchants that have previouslyprovided the service and attributes of different users that havepreviously requested the service; and providing access to the predictedforms to the customer.

In another aspect, an article of manufacture comprises a non-transitorymachine-readable medium storing instructions that, when executed,configure one or more computers to perform operations comprising:predicting that a customer of a plurality of customers is likely torequest a service wherein the prediction is based on historical datacomprising attributes of different customers that have previouslyrequested the service; predicting that one or more merchants of aplurality of merchants has a respective probability of being selected bythe customer to provide the service that meets a threshold, wherein thepredicting is based on historical data comprising attributes ofdifferent merchants that have previously provided the service; selectingone of the predicted merchants based on one or more criteria; schedulingan appointment for the service on a calendar of the customer and on acalendar of the selected merchant; and providing notification of theappointment to a customer device of the customer and a merchant deviceof the selected merchant.

In one implementation, scheduling the appointment comprises: sendinginformation to the customer device to cause the customer device tonotify the customer of the appointment; and after sending theinformation to the customer device, receiving from the customer devicean indication of acceptance of the appointment.

In one implementation, scheduling the appointment comprises: sendinginformation to the merchant device to cause the merchant device tonotify the merchant of the appointment; and after sending theinformation to the merchant device, receiving from the merchant devicean indication of acceptance of the appointment.

In one implementation, the notification is one or more of: audio,visual, and haptic.

In one implementation, predicting that the customer of the plurality ofcustomers is likely to request the service comprises: training aclassifier to predict whether a given customer would request the serviceusing the historical data comprising the attributes of differentcustomers that have requested the service; and providing attributes ofthe customer as input to the classifier and obtaining a prediction asoutput of the classifier.

In one implementation, predicting that a merchant of the plurality ofmerchants is likely to be selected by the customer comprises: training aclassifier to predict whether a given merchant would be selected toprovide the service using the historical data comprising the attributesof different merchants that have previously provided the service; andproviding attributes of the merchant as input to the classifier andobtaining a prediction as output of the classifier.

In one implementation, attributes of a particular customer comprises aplurality of the following: an identification attribute, a preferenceattribute, an asset attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:name, gender, driver's license number, social security number, no-showperformance, and home address; a particular preference attribute is oneof: level of feedback expected from merchants, type of service, whetherto automatically schedule appointments for services, whether to allowanother user to purchase an appointment, physical exercise preference,whether to follow scheduled maintenance, a preference of merchant for agiven service, and merchant location preference; a particular assetattribute is one of: primary care doctor, spouse/partner, home address,and vehicle identification number; and a particular task attribute isone of: car repair, car maintenance, doctor visit, exercise class,training, haircut, and spa appointment.

In one implementation, attributes of a particular merchant comprises aplurality of the following: an identification attribute, a preferenceattribute, a resource attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:business name, service sector, business address, gender, businesslicense, on-time performance, operating hours, type of personal careprovider, type of automotive service provider, type of buildingmaintenance provider, type of training provider, type of transportationservices provider, and type of healthcare provider; a particularpreference attribute is one of: resource utilization, accept weekendappointments, automatic appointment triage, accept emergency requests,accept insurance, and type of insurance accepted; a particular resourceattribute is one of: employee name, employee specialty, and currentlocation; and a particular task attribute is one of: car repair, carmaintenance, doctor visit, exercise class, haircut, and spa appointment.

In one implementation, a service is one of: car repair, car maintenance,doctor visit, exercise class, training, haircut, and spa appointment.

In one implementation, a particular criterion is: a distance between acurrent location of the customer device and the merchant, a customerapproval rating of the merchant, a preference of the customer, customerfeedback regarding the merchant, or a specialty of the merchant.

In one implementation, the customer device is one of: a smart phone, asmart watch, smart glasses, a portable computer, and a tablet computer.

In one implementation, the operations further comprise: predicting thatone or more forms of a plurality of forms are likely to be required forthe service, wherein the predicting is based on historical datacomprising attributes of different merchants that have previouslyprovided the service and attributes of different users that havepreviously requested the service; and providing access to the predictedforms to the customer.

In one aspect, a computer-implemented method comprises: identifying anappointment for a service scheduled on a calendar of a customer andscheduled on a calendar of a merchant; monitoring a location of acustomer device of the customer during a period of time before theappointment; estimating an arrival time of the customer at a location ofthe merchant based on a current time, a current location of the customerdevice, and the location of the merchant; determining that the customerwill be late for the appointment based on the estimated arrival time;and based on the determining, changing the appointment on the calendarof the merchant and on the calendar of the customer to accommodate thecustomer's estimated time of arrival at the location of the merchant.

In one implementation, changing the appointment comprises: providingnotification of the appointment change to the customer device and to amerchant device of the merchant; and receiving acceptance of theappointment change from the customer device and from the merchantdevice.

In one implementation, after changing the appointment on the calendar ofthe merchant and on the calendar of the customer to accommodate thecustomer's estimated time of arrival at the location of the merchant,the method further comprises: providing notification of the appointmentchange to the customer device or a merchant device of the merchant.

In one implementation, changing the appointment comprises: providingnotification that the customer will be late to a merchant device of themerchant; receiving a change to the appointment from the merchantdevice; providing notification of the appointment change to the customerdevice; and receiving acceptance of the appointment change from thecustomer device.

In one implementation, changing the appointment comprises: providingnotification to the customer device of the possibility of exchangingappointments with another customer of the merchant; and receivingacceptance of the appointment exchange from the customer device.

In one implementation, providing notification to the customer device ofthe other customer of the possibility of exchanging appointments withthe customer; and receiving acceptance of the appointment exchange fromthe customer device of the other customer.

In one implementation, the method comprises charging an account of thecustomer for the appointment change or crediting an account of the othercustomer for the appointment change.

In one implementation, crediting the account of the other customercomprises providing a discount for a service.

In one implementation, after determining that the customer will be late,the method further comprises: providing a notification to the customerdevice or a merchant device of the merchant that the customer will belate for the appointment.

In one implementation, the notification provides an option for cancelingthe appointment or rescheduling the appointment, and the method furthercomprises: receiving from the customer device a request to cancel orreschedule the appointment.

In one implementation, the method comprises debiting an account of thecustomer in response to receiving the request to cancel or reschedulethe appointment.

In one implementation, the method comprises estimating the arrival timeof the customer at the location of the merchant is further based on oneor more of: driving conditions and weather.

In one implementation, the customer device is one of: a smart phone, asmart watch, smart glasses, a portable computer, and a tablet computer.

In another aspect, a system comprises one or more computers programmedto perform operations comprising: identifying an appointment for aservice scheduled on a calendar of a customer and scheduled on acalendar of a merchant; monitoring a location of a customer device ofthe customer during a period of time before the appointment; estimatingan arrival time of the customer at a location of the merchant based on acurrent time, a current location of the customer device, and thelocation of the merchant; determining that the customer will be late forthe appointment based on the estimated arrival time; and based on thedetermining, changing the appointment on the calendar of the merchantand on the calendar of the customer to accommodate the customer'sestimated time of arrival at the location of the merchant.

In one implementation, changing the appointment comprises: providingnotification of the appointment change to the customer device and to amerchant device of the merchant; and receiving acceptance of theappointment change from the customer device and from the merchantdevice.

In one implementation, after changing the appointment on the calendar ofthe merchant and on the calendar of the customer to accommodate thecustomer's estimated time of arrival at the location of the merchant,the operations further comprise: providing notification of theappointment change to the customer device or a merchant device of themerchant.

In one implementation, changing the appointment comprises: providingnotification that the customer will be late to a merchant device of themerchant; receiving a change to the appointment from the merchantdevice; providing notification of the appointment change to the customerdevice; and receiving acceptance of the appointment change from thecustomer device.

In one implementation, changing the appointment comprises: providingnotification to the customer device of the possibility of exchangingappointments with another customer of the merchant; and receivingacceptance of the appointment exchange from the customer device.

In one implementation, the operations further comprise: providingnotification to the customer device of the other customer of thepossibility of exchanging appointments with the customer; and receivingacceptance of the appointment exchange from the customer device of theother customer.

In one implementation, the operations further comprise: charging anaccount of the customer for the appointment change or crediting anaccount of the other customer for the appointment change.

In one implementation, crediting the account of the other customercomprises providing a discount for a service.

In one implementation, after determining that the customer will be late,the operations further comprise: providing a notification to thecustomer device or a merchant device of the merchant that the customerwill be late for the appointment.

In one implementation, the notification provides an option for cancelingthe appointment or rescheduling the appointment, and wherein theoperations further comprise: receiving from the customer device arequest to cancel or reschedule the appointment.

In one implementation, the operations further comprise debiting anaccount of the customer in response to receiving the request to cancelor reschedule the appointment.

In one implementation, estimating the arrival time of the customer atthe location of the merchant is further based on one or more of: drivingconditions and weather.

In one implementation, the customer device is one of: a smart phone, asmart watch, smart glasses, a portable computer, and a tablet computer.

In another aspect, an article of manufacture comprises a non-transitorymachine-readable medium storing instructions that, when executed,configure one or more computers to perform operations comprising:identifying an appointment for a service scheduled on a calendar of acustomer and scheduled on a calendar of a merchant; monitoring alocation of a customer device of the customer during a period of timebefore the appointment; estimating an arrival time of the customer at alocation of the merchant based on a current time, a current location ofthe customer device, and the location of the merchant; determining thatthe customer will be late for the appointment based on the estimatedarrival time; and based on the determining, changing the appointment onthe calendar of the merchant and on the calendar of the customer toaccommodate the customer's estimated time of arrival at the location ofthe merchant.

In one implementation, changing the appointment comprises: providingnotification of the appointment change to the customer device and to amerchant device of the merchant; and receiving acceptance of theappointment change from the customer device and from the merchantdevice.

In one implementation, after changing the appointment on the calendar ofthe merchant and on the calendar of the customer to accommodate thecustomer's estimated time of arrival at the location of the merchant,the operations further comprise: providing notification of theappointment change to the customer device or a merchant device of themerchant.

In one implementation, changing the appointment comprises: providingnotification that the customer will be late to a merchant device of themerchant; receiving a change to the appointment from the merchantdevice; providing notification of the appointment change to the customerdevice; and receiving acceptance of the appointment change from thecustomer device.

In one implementation, changing the appointment comprises: providingnotification to the customer device of the possibility of exchangingappointments with another customer of the merchant; and receivingacceptance of the appointment exchange from the customer device.

In one implementation, the operations further comprise: providingnotification to the customer device of the other customer of thepossibility of exchanging appointments with the customer; and receivingacceptance of the appointment exchange from the customer device of theother customer.

In one implementation, the operations further comprise: charging anaccount of the customer for the appointment change or crediting anaccount of the other customer for the appointment change.

In one implementation, crediting the account of the other customercomprises providing a discount for a service.

In one implementation, after determining that the customer will be late,the operations further comprise: providing a notification to thecustomer device or a merchant device of the merchant that the customerwill be late for the appointment.

In one implementation, the notification provides an option for cancelingthe appointment or rescheduling the appointment, and wherein theoperations further comprise: receiving from the customer device arequest to cancel or reschedule the appointment.

In one implementation, the operations further comprise debiting anaccount of the customer in response to receiving the request to cancelor reschedule the appointment.

In one implementation, estimating the arrival time of the customer atthe location of the merchant is further based on one or more of: drivingconditions and weather.

In one implementation, the customer device is one of: a smart phone, asmart watch, smart glasses, a portable computer, and a tablet computer.

In one aspect, a computer-implemented method comprises: receiving arequest from a customer device of a first customer to purchase anappointment for a service; identifying one or more second customers thateach have a respective appointment for the service on a respectivecalendar of the second customer wherein the appointment is scheduled ona respective calendar of a respective merchant; identifying one or moreof the appointments based on, at least, one or more criteria; receivingfrom the customer device of the first customer selection of one of theidentified appointments; providing an offer to sell the selectedappointment to a customer device of the second customer that has theappointment scheduled on their respective calendar; receiving acceptanceof the offer to sell the selected appointment from the customer deviceof the second customer that has the appointment scheduled on theirrespective calendar; removing the selected appointment from therespective calendar of the second customer and adding the selectedappointment to the calendar of the first customer; and updating theappointment scheduled on the respective calendar of one of therespective merchants to reflect that the appointment is with the firstuser.

In one implementation, a particular criterion is a distance between alocation of the first customer and a location of the merchant that hasthe respective appointment scheduled on their respective calendar, acustomer approval rating of the merchant, a preferred time or time rangefor the appointment, a preference of the first customer, customerfeedback regarding the merchant, a specialty of the merchant, or aprediction that the first customer would likely select the merchant toprovide the service.

In one implementation, the prediction that the first customer wouldlikely select the merchant to provide the service is obtained bypredicting based on historical data comprising attributes of differentmerchants and attributes of the first customer.

In one implementation, the method comprises: training a classifier topredict whether a given merchant would be selected to provide theservice using the historical data; and providing attributes of themerchant and the attributes of the first customer as input to theclassifier and obtaining the prediction as output of the classifier.

In one implementation, a particular criterion is whether the merchantthat has the respective appointment scheduled on their respectivecalendar would have access to information from one or more priorappointments for the service for the first customer.

In one implementation, the method comprises debiting an account of thefirst customer.

In one implementation, the method comprises crediting an account of thesecond customer that has the appointment scheduled on their respectivecalendar.

In one implementation, the method comprises providing informationregarding the identified appointments to the customer device of thefirst customer.

In one implementation, the customer device of the first customer is oneof: a smart phone, a smart watch, smart glasses, a portable computer,and a tablet computer.

In another aspect, a system comprises one or more computers programmedto perform operations comprising: receiving a request from a customerdevice of a first customer to purchase an appointment for a service;identifying one or more second customers that each have a respectiveappointment for the service on a respective calendar of the secondcustomer wherein the appointment is scheduled on a respective calendarof a respective merchant; identifying one or more of the appointmentsbased on, at least, one or more criteria; receiving from the customerdevice of the first customer selection of one of the identifiedappointments; providing an offer to sell the selected appointment to acustomer device of the second customer that has the appointmentscheduled on their respective calendar; receiving acceptance of theoffer to sell the selected appointment from the customer device of thesecond customer that has the appointment scheduled on their respectivecalendar; removing the selected appointment from the respective calendarof the second customer and adding the selected appointment to thecalendar of the first customer; and updating the appointment scheduledon the respective calendar of one of the respective merchants to reflectthat the appointment is with the first user.

In one implementation, a particular criterion is: a distance between alocation of the first customer and a location of the merchant that hasthe respective appointment scheduled on their respective calendar, acustomer approval rating of the merchant, a preferred time or time rangefor the appointment, a preference of the first customer, customerfeedback regarding the merchant, a specialty of the merchant, or aprediction that the first customer would likely select the merchant toprovide the service.

In one implementation, the prediction that the first customer wouldlikely select the merchant to provide the service is obtained bypredicting based on historical data comprising attributes of differentmerchants and attributes of the first customer.

In one implementation, the operations further comprise: training aclassifier to predict whether a given merchant would be selected toprovide the service using the historical data; and providing attributesof the merchant and the attributes of the first customer as input to theclassifier and obtaining the prediction as output of the classifier.

In one implementation, a particular criterion is whether the merchantthat has the respective appointment scheduled on their respectivecalendar would have access to information from one or more priorappointments for the service for the first customer.

In one implementation, the operations further comprise debiting anaccount of the first customer.

In one implementation, the operations further comprise crediting anaccount of the second customer that has the appointment scheduled ontheir respective calendar.

In one implementation, the operations further comprise providinginformation regarding the identified appointments to the customer deviceof the first customer.

In one implementation, the customer device of the first customer is oneof: a smart phone, a smart watch, smart glasses, a portable computer,and a tablet computer.

In another aspect, an article of manufacture comprises a non-transitorymachine-readable medium storing instructions that, when executed,configure one or more computers to perform operations comprising:receiving a request from a customer device of a first customer topurchase an appointment for a service; identifying one or more secondcustomers that each have a respective appointment for the service on arespective calendar of the second customer wherein the appointment isscheduled on a respective calendar of a respective merchant; identifyingone or more of the appointments based on, at least, one or morecriteria; receiving from the customer device of the first customerselection of one of the identified appointments; providing an offer tosell the selected appointment to a customer device of the secondcustomer that has the appointment scheduled on their respectivecalendar; receiving acceptance of the offer to sell the selectedappointment from the customer device of the second customer that has theappointment scheduled on their respective calendar; removing theselected appointment from the respective calendar of the second customerand adding the selected appointment to the calendar of the firstcustomer; and updating the appointment scheduled on the respectivecalendar of one of the respective merchants to reflect that theappointment is with the first user.

In one implementation, a particular criterion is: a distance between alocation of the first customer and a location of the merchant that hasthe respective appointment scheduled on their respective calendar, acustomer approval rating of the merchant, a preferred time or time rangefor the appointment, a preference of the first customer, customerfeedback regarding the merchant, a specialty of the merchant, or aprediction that the first customer would likely select the merchant toprovide the service.

In one implementation, the prediction that the first customer wouldlikely select the merchant to provide the service is obtained bypredicting based on historical data comprising attributes of differentmerchants and attributes of the first customer.

In one implementation, the operations further comprise: training aclassifier to predict whether a given merchant would be selected toprovide the service using the historical data; and providing attributesof the merchant and the attributes of the first customer as input to theclassifier and obtaining the prediction as output of the classifier.

In one implementation, a particular criterion is whether the merchantthat has the respective appointment scheduled on their respectivecalendar would have access to information from one or more priorappointments for the service for the first customer.

In one implementation, the operations further comprise debiting anaccount of the first customer.

In one implementation, the operations further comprise crediting anaccount of the second customer that has the appointment scheduled ontheir respective calendar.

In one implementation, the operations further comprise providinginformation regarding the identified appointments to the customer deviceof the first customer.

In one implementation, the customer device of the first customer is oneof: a smart phone, a smart watch, smart glasses, a portable computer,and a tablet computer.

In one aspect, a computer-implemented method comprises: obtaining anadverse report against a merchant by a customer regarding an issue witha previously scheduled appointment for a service that was scheduled on acalendar of the customer and on a calendar of the merchant; predictingthat a solution of a plurality of different solutions has a respectiveprobability of resolving the issue that meets a threshold, wherein thepredicting is based on historical data comprising attributes ofdifferent customers that were satisfied by the solution for the issuegiven the service and attributes of the merchant; providing the adversereport and the predicted solution to a merchant device of the merchant;and within a pre-determined period of time, if a proposed resolution isnot received from the merchant device, publishing the adverse report;otherwise, if a proposed resolution is received from the merchantdevice, storing the adverse report in a non-publishable state.

In one implementation, publishing the adverse report comprises: enablingthe customer to modify the adverse report before the adverse report ispublished; receiving a modification to the adverse report from acustomer device of the customer; and including the modification in thepublished adverse report.

In one implementation, the method further comprises, after storing theadverse report in the non-publishable state, publishing the adversereport.

In one implementation, the method further comprises enabling thecustomer to cancel publication of the adverse report.

In one implementation, after receiving the proposed resolution, themethod further comprises: enabling the customer to provide negotiationfeedback regarding the proposed resolution; receiving the negotiationfeedback from a customer device of the customer; assigning a feedbackrating to the negotiation feedback; and publishing the assigned feedbackrating.

In one implementation, enabling the customer to provide negotiationfeedback comprises generating a plurality of questions about servicesprovided by the merchant and providing the customer device with at leastone of the questions.

In one implementation, the method further comprises: monitoringpublished adverse reports against a particular merchant; and assigning arating to the particular merchant based on, at least, the publishedadverse reports.

In one implementation, assigning the rating to the particular merchantis further based on, at least, proposed resolutions received from themerchant device.

In one implementation, predicting that the solution will resolve theissue comprises: training a classifier to predict whether a givensolution will resolve the issue using historical data comprisingattributes of different customers that were satisfied by the solution,the service, and attributes of the merchant; and providing attributes ofthe customer as input to the classifier and obtaining a prediction asoutput of the classifier.

In another aspect, a system comprises one or more computers programmedto perform operations comprising: obtaining an adverse report against amerchant by a customer regarding an issue with a previously scheduledappointment for a service that was scheduled on a calendar of thecustomer and on a calendar of the merchant; predicting that a solutionof a plurality of different solutions has a respective probability ofresolving the issue that meets a threshold, wherein the predicting isbased on historical data comprising attributes of different customersthat were satisfied by the solution for the issue given the service andattributes of the merchant; providing the adverse report and thepredicted solution to a merchant device of the merchant; and within apre-determined period of time, if a proposed resolution is not receivedfrom the merchant device, publishing the adverse report; otherwise, if aproposed resolution is received from the merchant device, storing theadverse report in a non-publishable state.

In one implementation, publishing the adverse report comprises: enablingthe customer to modify the adverse report before the adverse report ispublished; receiving a modification to the adverse report from acustomer device of the customer; and including the modification in thepublished adverse report.

In one implementation, the operations further comprise, after storingthe adverse report in the non-publishable state, publishing the adversereport.

In one implementation, the operations further comprise enabling thecustomer to cancel publication of the adverse report.

In one implementation, after receiving the proposed resolution, theoperations further comprise: enabling the customer to providenegotiation feedback regarding the proposed resolution; receiving thenegotiation feedback from a customer device of the customer; assigning afeedback rating to the negotiation feedback; and publishing the assignedfeedback rating.

In one implementation, enabling the customer to provide negotiationfeedback comprises generating a plurality of questions about servicesprovided by the merchant and providing the customer device with at leastone of the questions.

In one implementation, the operations further comprise: monitoringpublished adverse reports against a particular merchant; and assigning arating to the particular merchant based on, at least, the publishedadverse reports.

In one implementation, assigning the rating to the particular merchantis further based on, at least, proposed resolutions received from themerchant device.

In one implementation, predicting that the solution will resolve theissue comprises: training a classifier to predict whether a givensolution will resolve the issue using historical data comprisingattributes of different customers that were satisfied by the solution,the service, and attributes of the merchant; and providing attributes ofthe customer as input to the classifier and obtaining a prediction asoutput of the classifier.

In another aspect, an article of manufacture comprises a non-transitorymachine-readable medium storing instructions that, when executed,configure one or more computers to perform operations comprising:obtaining an adverse report against a merchant by a customer regardingan issue with a previously scheduled appointment for a service that wasscheduled on a calendar of the customer and on a calendar of themerchant; predicting that a solution of a plurality of differentsolutions has a respective probability of resolving the issue that meetsa threshold, wherein the predicting is based on historical datacomprising attributes of different customers that were satisfied by thesolution for the issue given the service and attributes of the merchant;providing the adverse report and the predicted solution to a merchantdevice of the merchant; and within a pre-determined period of time, if aproposed resolution is not received from the merchant device, publishingthe adverse report; otherwise, if a proposed resolution is received fromthe merchant device, storing the adverse report in a non-publishablestate.

In one implementation, publishing the adverse report comprises: enablingthe customer to modify the adverse report before the adverse report ispublished; receiving a modification to the adverse report from acustomer device of the customer; and including the modification in thepublished adverse report.

In one implementation, the operations further comprise, after storingthe adverse report in the non-publishable state, publishing the adversereport.

In one implementation, the operations further comprise enabling thecustomer to cancel publication of the adverse report.

In one implementation, after receiving the proposed resolution, theoperations further comprise: enabling the customer to providenegotiation feedback regarding the proposed resolution; receiving thenegotiation feedback from a customer device of the customer; assigning afeedback rating to the negotiation feedback; and publishing the assignedfeedback rating.

In one implementation, enabling the customer to provide negotiationfeedback comprises generating a plurality of questions about servicesprovided by the merchant and providing the customer device with at leastone of the questions.

In one implementation, the operations further comprise: monitoringpublished adverse reports against a particular merchant; and assigning arating to the particular merchant based on, at least, the publishedadverse reports.

In one implementation, assigning the rating to the particular merchantis further based on, at least, proposed resolutions received from themerchant device.

In one implementation, predicting that the solution will resolve theissue comprises: training a classifier to predict whether a givensolution will resolve the issue using historical data comprisingattributes of different customers that were satisfied by the solution,the service, and attributes of the merchant; and providing attributes ofthe customer as input to the classifier and obtaining a prediction asoutput of the classifier.

In one aspect, a computer-implemented method comprises: determining, foreach of a plurality of different merchants, a respective on-timeperformance of the merchant wherein the on-time performance of themerchant is a measure of appointment schedule adherence of the merchant;receiving a request for a service for a customer; selecting a merchantfrom a plurality of the merchants to provide the service wherein theon-time performance of the selected merchant meets a threshold level oftimeliness, and wherein the threshold level of timeliness is based on,at least, the service; scheduling an appointment for the service on acalendar of the selected merchant on a calendar of the customer; andmonitoring the merchant calendar and the customer calendar for changesto the appointment.

In one implementation, the request for the service is received from acustomer device of the customer or from a device of a third party.

In one implementation, the customer device is one of: a smart phone, asmart watch, smart glasses, a portable computer, and a tablet computer.

In one implementation, scheduling the appointment comprises: providinghistorical data regarding on-time performance of the customer to amerchant device of the selected merchant; and enabling the selectedmerchant to opt out of providing the service to the customer.

In one implementation, scheduling the appointment comprises: providinghistorical data regarding on-time performance of the selected merchantto a customer device of the customer; and enabling the customer to optout of receiving the service from the selected merchant.

In one implementation, selecting the merchant comprises: predicting thata particular merchant has a respective probability of being selected bythe customer to provide the service that meets a threshold, wherein thepredicting is based on historical data comprising attributes ofdifferent merchants that have previously provided the service andattributes of the customer; and selecting the particular merchant toprovide the service.

In one implementation, selecting the merchant comprises: determiningthat the particular merchant has a higher probability than all of theother merchants; and receiving selection of the particular merchant froma customer device of the customer.

In one implementation, monitoring the merchant calendar and the customercalendar comprises monitoring a geographical location of a customerdevice of the customer to determine if the customer will be late for theappointment based on an estimated arrival time of the customer at alocation of the merchant.

In one implementation, the method further comprises providingnotification to at least one of the customer device and a merchantdevice of the merchant if the customer will be late for the appointment.

In one implementation, the method comprises receiving a change to theappointment from the merchant device; providing notification of theappointment change to the customer device; and receiving acceptance ofthe appointment change from the customer device.

In another aspect, a system comprises one or more computers programmedto perform operations comprising: determining, for each of a pluralityof different merchants, a respective on-time performance of the merchantwherein the on-time performance of the merchant is a measure ofappointment schedule adherence of the merchant; receiving a request fora service for a customer; selecting a merchant from a plurality of themerchants to provide the service wherein the on-time performance of theselected merchant meets a threshold level of timeliness, and wherein thethreshold level of timeliness is based on, at least, the service;scheduling an appointment for the service on a calendar of the selectedmerchant on a calendar of the customer; and monitoring the merchantcalendar and the customer calendar for changes to the appointment.

In one implementation, the request for the service is received from acustomer device of the customer or from a device of a third party.

In one implementation, the customer device is one of: a smart phone, asmart watch, smart glasses, a portable computer, and a tablet computer.

In one implementation, scheduling the appointment comprises: providinghistorical data regarding on-time performance of the customer to amerchant device of the selected merchant; and enabling the selectedmerchant to opt out of providing the service to the customer.

In one implementation, scheduling the appointment comprises: providinghistorical data regarding on-time performance of the selected merchantto a customer device of the customer; and enabling the customer to optout of receiving the service from the selected merchant.

In one implementation, selecting the merchant comprises: predicting thata particular merchant has a respective probability of being selected bythe customer to provide the service that meets a threshold, wherein thepredicting is based on historical data comprising attributes ofdifferent merchants that have previously provided the service andattributes of the customer; and selecting the particular merchant toprovide the service.

In one implementation, selecting the merchant comprises: determiningthat the particular merchant has a higher probability than all of theother merchants; and receiving selection of the particular merchant froma customer device of the customer.

In one implementation, monitoring the merchant calendar and the customercalendar comprises monitoring a geographical location of a customerdevice of the customer to determine if the customer will be late for theappointment based on an estimated arrival time of the customer at alocation of the merchant.

In one implementation, the operations further comprise providingnotification to at least one of the customer device and a merchantdevice of the merchant if the customer will be late for the appointment.

In one implementation, the operations further comprise: receiving achange to the appointment from the merchant device; providingnotification of the appointment change to the customer device; andreceiving acceptance of the appointment change from the customer device.

In another aspect, an article of manufacture comprises a non-transitorymachine-readable medium storing instructions that, when executed,configure one or more computers to perform operations comprising:determining, for each of a plurality of different merchants, arespective on-time performance of the merchant wherein the on-timeperformance of the merchant is a measure of appointment scheduleadherence of the merchant; receiving a request for a service for acustomer; selecting a merchant from a plurality of the merchants toprovide the service wherein the on-time performance of the selectedmerchant meets a threshold level of timeliness, and wherein thethreshold level of timeliness is based on, at least, the service;scheduling an appointment for the service on a calendar of the selectedmerchant on a calendar of the customer; and monitoring the merchantcalendar and the customer calendar for changes to the appointment.

In one implementation, the request for the service is received from acustomer device of the customer or from a device of a third party.

In one implementation, the customer device is one of: a smart phone, asmart watch, smart glasses, a portable computer, and a tablet computer.

In one implementation, scheduling the appointment comprises: providinghistorical data regarding on-time performance of the customer to amerchant device of the selected merchant; and enabling the selectedmerchant to opt out of providing the service to the customer.

In one implementation, scheduling the appointment comprises: providinghistorical data regarding on-time performance of the selected merchantto a customer device of the customer; and enabling the customer to optout of receiving the service from the selected merchant.

In one implementation, selecting the merchant comprises: predicting thata particular merchant has a respective probability of being selected bythe customer to provide the service that meets a threshold, wherein thepredicting is based on historical data comprising attributes ofdifferent merchants that have previously provided the service andattributes of the customer; and selecting the particular merchant toprovide the service.

In one implementation, selecting the merchant comprises: determiningthat the particular merchant has a higher probability than all of theother merchants; and receiving selection of the particular merchant froma customer device of the customer.

In one implementation, monitoring the merchant calendar and the customercalendar comprises monitoring a geographical location of a customerdevice of the customer to determine if the customer will be late for theappointment based on an estimated arrival time of the customer at alocation of the merchant.

In one implementation, the operations further comprise providingnotification to at least one of the customer device and a merchantdevice of the merchant if the customer will be late for the appointment.

In one implementation, the operations further comprise: receiving achange to the appointment from the merchant device; providingnotification of the appointment change to the customer device; andreceiving acceptance of the appointment change from the customer device.

In one aspect, a computer-implemented method comprises: obtaining aplurality of attributes for a particular customer and identification ofa service; predicting that each of a plurality of merchants has arespective probability of being selected by the customer to provide theservice that meets a threshold, wherein the predicting is based onhistorical data comprising attributes of different merchants that havepreviously provided the service to customers that have attributessimilar to those of the particular customer; and obtaining, for each ofthe merchants, cost information based on amounts paid by respectivecustomers for receiving the service from the merchant; and providing therespective information to the particular customer.

In one implementation, obtaining the cost information comprisescombining the cost information such that identifying information of themerchant and the respective customers is removed.

In one implementation, obtaining the cost information comprisesautomatically collecting billing documentation from the merchant, thebilling documentation comprising the amounts paid by the respectivecustomers.

In one implementation, the method further comprises providing therespective information to one or more merchants of the plurality ofmerchants.

In one implementation, predicting that a merchant of the plurality ofmerchants is likely to be selected by the customer comprises: training aclassifier to predict whether a given merchant would be selected toprovide the service using the historical data comprising the attributesof different merchants that have previously provided the service; andproviding attributes of the merchant as input to the classifier andobtaining a prediction as output of the classifier.

In one implementation, the attributes of the merchant comprise aplurality of the following: an identification attribute, a preferenceattribute, a resource attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:business name, service sector, business address, gender, businesslicense, on time performance, operating hours, type of personal careprovider, type of automotive service provider, type of buildingmaintenance provider, type of training provider, type of transportationservices provider, and type of healthcare provider; a particularpreference attribute is one of: resource utilization, accept weekendappointments, automatic appointment triage, accept emergency requests,accept insurance, and type of insurance accepted; a particular resourceattribute is one of: employee name, employee specialty, and currentlocation; and a particular task attribute is one of: car repair, carmaintenance, doctor visit, exercise class, haircut, and spa appointment.

In one implementation, the attributes of the customer comprise aplurality of the following: an identification attribute, a preferenceattribute, an asset attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:name, gender, driver's license number, social security number, no-showperformance, and home address; a particular preference attribute is oneof: level of feedback expected from merchants, type of service, whetherto automatically schedule appointments for services, whether to allowanother user to purchase an appointment, physical exercise preference,whether to follow scheduled maintenance, a preference of merchant for agiven service, and merchant location preference; wherein a particularasset attribute is one of: primary care doctor, spouse/partner, homeaddress, and vehicle identification number; and wherein a particulartask attribute is one of: car repair, car maintenance, doctor visit,exercise class, training, haircut, and spa appointment.

In one implementation, the service is one of: car repair, carmaintenance, doctor visit, exercise class, training, haircut, and spaappointment.

In another aspect, a system comprises one or more computers programmedto perform operations comprising: obtaining a plurality of attributesfor a particular customer and identification of a service; predictingthat each of a plurality of merchants has a respective probability ofbeing selected by the customer to provide the service that meets athreshold, wherein the predicting is based on historical data comprisingattributes of different merchants that have previously provided theservice to customers that have attributes similar to those of theparticular customer; and obtaining, for each of the merchants, costinformation based on amounts paid by respective customers for receivingthe service from the merchant; and providing the respective informationto the particular customer.

In one implementation, obtaining the cost information comprisescombining the cost information such that identifying information of themerchant and the respective customers is removed.

In one implementation, obtaining the cost information comprisesautomatically collecting billing documentation from the merchant, thebilling documentation comprising the amounts paid by the respectivecustomers.

In one implementation, the operations further comprise providing therespective information to one or more merchants of the plurality ofmerchants.

In one implementation, predicting that a merchant of the plurality ofmerchants is likely to be selected by the customer comprises: training aclassifier to predict whether a given merchant would be selected toprovide the service using the historical data comprising the attributesof different merchants that have previously provided the service; andproviding attributes of the merchant as input to the classifier andobtaining a prediction as output of the classifier.

In one implementation, the attributes of the merchant comprise aplurality of the following: an identification attribute, a preferenceattribute, a resource attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:business name, service sector, business address, gender, businesslicense, on time performance, operating hours, type of personal careprovider, type of automotive service provider, type of buildingmaintenance provider, type of training provider, type of transportationservices provider, and type of healthcare provider; a particularpreference attribute is one of: resource utilization, accept weekendappointments, automatic appointment triage, accept emergency requests,accept insurance, and type of insurance accepted; a particular resourceattribute is one of: employee name, employee specialty, and currentlocation; and a particular task attribute is one of: car repair, carmaintenance, doctor visit, exercise class, haircut, and spa appointment.

In one implementation, the attributes of the customer comprise aplurality of the following: an identification attribute, a preferenceattribute, an asset attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:name, gender, driver's license number, social security number, no-showperformance, and home address; a particular preference attribute is oneof: level of feedback expected from merchants, type of service, whetherto automatically schedule appointments for services, whether to allowanother user to purchase an appointment, physical exercise preference,whether to follow scheduled maintenance, a preference of merchant for agiven service, and merchant location preference; a particular assetattribute is one of: primary care doctor, spouse/partner, home address,and vehicle identification number; and a particular task attribute isone of: car repair, car maintenance, doctor visit, exercise class,training, haircut, and spa appointment.

In one implementation, the service is one of: car repair, carmaintenance, doctor visit, exercise class, training, haircut, and spaappointment.

In another aspect, an article of manufacture comprises a non-transitorymachine-readable medium storing instructions that, when executed,configure one or more computers to perform operations comprising:obtaining a plurality of attributes for a particular customer andidentification of a service; predicting that each of a plurality ofmerchants has a respective probability of being selected by the customerto provide the service that meets a threshold, wherein the predicting isbased on historical data comprising attributes of different merchantsthat have previously provided the service to customers that haveattributes similar to those of the particular customer; and obtaining,for each of the merchants, cost information based on amounts paid byrespective customers for receiving the service from the merchant; andproviding the respective information to the particular customer.

In one implementation, obtaining the cost information comprisescombining the cost information such that identifying information of themerchant and the respective customers is removed.

In one implementation, obtaining the cost information comprisesautomatically collecting billing documentation from the merchant, thebilling documentation comprising the amounts paid by the respectivecustomers.

In one implementation, the operations further comprise providing therespective information to one or more merchants of the plurality ofmerchants.

In one implementation, predicting that a merchant of the plurality ofmerchants is likely to be selected by the customer comprises: training aclassifier to predict whether a given merchant would be selected toprovide the service using the historical data comprising the attributesof different merchants that have previously provided the service; andproviding attributes of the merchant as input to the classifier andobtaining a prediction as output of the classifier.

In one implementation, the attributes of the merchant comprise aplurality of the following: an identification attribute, a preferenceattribute, a resource attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:business name, service sector, business address, gender, businesslicense, on time performance, operating hours, type of personal careprovider, type of automotive service provider, type of buildingmaintenance provider, type of training provider, type of transportationservices provider, and type of healthcare provider; a particularpreference attribute is one of: resource utilization, accept weekendappointments, automatic appointment triage, accept emergency requests,accept insurance, and type of insurance accepted; a particular resourceattribute is one of: employee name, employee specialty, and currentlocation; and a particular task attribute is one of: car repair, carmaintenance, doctor visit, exercise class, haircut, and spa appointment.

In one implementation, the attributes of the customer comprise aplurality of the following: an identification attribute, a preferenceattribute, an asset attribute, and a task attribute.

In one implementation, a particular identification attribute is one of:name, gender, driver's license number, social security number, no-showperformance, and home address; a particular preference attribute is oneof: level of feedback expected from merchants, type of service, whetherto automatically schedule appointments for services, whether to allowanother user to purchase an appointment, physical exercise preference,whether to follow scheduled maintenance, a preference of merchant for agiven service, and merchant location preference; a particular assetattribute is one of: primary care doctor, spouse/partner, home address,and vehicle identification number; and a particular task attribute isone of: car repair, car maintenance, doctor visit, exercise class,training, haircut, and spa appointment.

In one implementation, the service is one of: car repair, carmaintenance, doctor visit, exercise class, training, haircut, and spaappointment.

The details of one or more implementations of the subject matterdescribed in the present specification are set forth in the accompanyingdrawings and the description below. Other features, aspects, andadvantages of the subject matter will become apparent from thedescription, the drawings, and the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, like reference characters generally refer to the sameparts throughout the different views. Also, the drawings are notnecessarily to scale, emphasis instead generally being placed uponillustrating the principles of the implementations. In the followingdescription, various implementations are described with reference to thefollowing drawings, in which:

FIG. 1 is a diagram illustrating an example marketplace matching system.

FIG. 2 is a diagram illustrating example functions and interfaces of amarketplace matching system.

FIG. 3 is a flowchart illustrating an example appointment predictiontechnique.

FIG. 4 is a flowchart illustrating an example appointment triage methodimplementation

FIG. 5 is a flowchart illustrating an example appointment exchangetechnique.

FIG. 6 is a flowchart illustrating an example bilateral communicationtechnique.

FIG. 7 is a flowchart illustrating an example appointment certificationtechnique.

FIG. 8 is a flowchart illustrating an example merchant benchmarkingtechnique.

DETAILED DESCRIPTION

Described herein in various implementations are systems and accompanyingmethods for matching consumers and service providers, including anonline, real-time, marketplace to match and connect consumers withmerchants and professionals to buy and sell consumer services; amatching system and method for an online marketplace for the sourcing,marketing, sale and delivery of consumer services using buyer and sellerpreferences and histories; an Internet cloud-based hardware server(s)that is connected with a secure Buyer Matching Engine and a secureSeller Matching Engine and that offers a secure marketplace environmentfor the sourcing and marketing, sale and acquisition, delivery andacceptance, payment, feedback, and electronic digital archiving ofconsumer services; and an Internet marketplace with tightly integratedmarketplace services for the purchase and sale of consumer services thatis based on an Internet application where individual consumer'scalendars are maintained to manage their daily life activities for themaintenance of their personal health and services, the health of theirfamily, the maintenance of their assets, and so forth. The sameapplication can also be used by merchants and service professionals tomaintain complete operating schedules for all productive assets used togenerate their service income.

As used herein, a “merchant” is a person, organization, or entity thatoperates in the business of selling services and/or goods. A “merchant”can include a service provider that accepts scheduled appointments withcustomers, including, but not limited to, an automotive mechanic, amedical professional, a lawyer, a photographer, a massage therapist, adentist, a hairdresser, and the like. A “customer,” or “consumer,” is aperson, organization, or entity that purchases services and/or goodsprovided by a merchant, and can include, for example, a person orcompany that schedules a service appointment with a merchant in order toreceive the service at a predefined time. “Services” are provided by amerchant and offer a benefit to a customer. By way of example,“services” can include automotive maintenance and repair, health andbeauty services, training, photography, legal services, and so on.

The Matching Process

Matching is the process by which the needs of the consumer are alignedwith the capabilities of the merchant. The closer the alignment of theparticulars of what the consumer desires, the more successful the matchwill be. As used in conjunction with the techniques described herein,“matching” refers to the needs of the consumer being aligned with thecapabilities of the merchant or professional. In one implementation,there are three types of matches that can be made when consumers arealigning with merchants.

A manual match occurs where the consumer sees what is being offered(e.g., on a webpage or in a newspaper) and makes a decision to acceptand therefore to confirm the transaction. In this case the confirmationof a service appointment under the arrangements offered, which caninclude, but not necessarily be limited to, time, cost, servicesincluded, and location, is made. In this particular process, a consumerhas not provided the merchant with the details of what they are seeking.The consumer has merely encountered an offer, found the detailsacceptable, and taken action to accept the offer or to follow-throughand make an appointment for the service.

An option match occurs when the consumer provides information, e.g.,through preferences, and a so-called matching engine determines that thepreferences align with the merchant or professional closely enough forthe match to be suggested to the consumer. This particular type of matchdoes not require that every preference is lined up but that a thresholdnumber of preferences match in some manner. An example of an optionmatch relates to a consumer who has defined very specific preferences,such as a specific price, time, feedback rating, etc. and the merchant'songoing data (i.e., the merchant's past and present data, including,e.g., past, present and future scheduled appointments, prices forservices, on-time performance, feedback ratings, and so on) either matchor substantially match (e.g., meet a matching threshold of 50% orgreater, 60% or greater, 70% or greater, 80% or greater, 90% or greater,and so on). In addition, there are a number of options in which some,but not all, of the preferences are matched. The options are presentedto the consumer for their conscious, real-time decision and the consumeris required to take action to follow-through.

An automatic match can occur when every preference (or substantially allof the preferences) of the consumer, as well as all or substantially allrelated ongoing data (i.e., the consumer's past and present data,including, e.g., past, present and future scheduled appointments,service price preferences, on-time performance, merchant ratingpreferences, and so on), is aligned with the offering of the merchant orprofessional: the match is automatically made, an appointment commitmentis completed, and neither the consumer nor the merchant or professionalmake conscious, real-time acceptance actions, which, instead, are madeby proxy on their behalf by the system. A simple or direct example of anautomatic match involves a transaction between a consumer and a merchantthat the consumer has used in the past. Another example would involve aconsumer who is seeking a haircut appointment at 12:00 p.m. on Fridayfrom a barber with a feedback rating of 4 or greater on a scale of 5, ata cost not to exceed $25 and at a business location that is within a twoblock radius of the consumer's place of work. If everything lines up, amatch can be made and the service appointment can be automaticallyscheduled.

Thus, the present disclosure describes methods and either automatic ornotification processes that effectively handle all three types ofmatches. In addition, when the three types of matches are combined withthe consumer's ability to set preferences in their personal profile, orwhere the merchant is able to set preferences in their business profile,there are unlimited variations of the three types of matches and eachconsumer and merchant can engage in transactions and confirmations thatmeet their specific needs in an automated environment.

In some implementations, the matching process is facilitated orautomatically performed using machine learning, pattern recognition,data mining, statistical correlation, and other suitable knowntechniques. In one example, the merchant and consumer attributes can beviewed as vectors in a multi-dimensional space (i.e., a consumerattribute vector and a merchant attribute vector), and the similaritybetween relevant attributes (e.g., a “match” between a merchant's ratingand a consumer's desired rating) can be determined based on a cosineangle between vectors. As another example, a decision tree can be usedas a predictive model which maps observations about merchant andconsumer attributes to determine whether particular attributes signify aparticular conclusion (e.g., whether a consumer is likely to choose aparticular merchant based on the merchant's location). In anotherexample, sets of data including merchant attributes and consumerattributes are correlating to determine a statistical relationship, ordependence. Using this technique, the system may, e.g., predict howlikely a consumer is to select a merchant to provide a service based onthe price the merchant charges for the service.

With some machine learning techniques, a classifier (e.g., a suitablealgorithm that categorizes new observations) can be trained over timeusing various historical data, such as customer attributes, merchantattributes, service purchases by customers, services offered bymerchants, service prices charged by merchants and costs incurred bycustomers, service completion times, customer and merchant timeliness,ratings, issue resolutions, and other data related to a customer,merchant, service, or the like that can be input to a classifier andallow the present system to make predictions about customer or merchantbehaviors, merchant and service recommendations, and so forth, asfurther described herein. For example, if the training data for aclassifier include two attributes (car make and geographic location of acustomer), and the classifier output is a prediction whether thecustomer would choose to get service from Joe's Garage, the trainingdata could include (1) Make: BMW, Location: San Francisco, ChooseService: No; (2) Make: Mercedes, Location: San Jose, Choose Service:Yes; (3) Make: Honda, Location: Menlo Park, Choose Service: Yes; etc. Acustomer's car make and location can then be input to the trainedclassifier to obtain as output a prediction of whether the service willbe chosen.

Attributes are characteristics, properties, or preferences associatedwith a merchant or consumer. Consumer identification attributes specifyidentifying information about a consumer, such as name, gender, driver'slicense number, social security number, no-show performance, and homeaddress. Consumer preference attributes represent a consumer's choiceswith respect to various system settings, services, or other items. Forexample, consumer preference attributes can include: level of feedbackexpected from merchants, type of service, whether to automaticallyschedule appointments for services, whether to allow another user topurchase an appointment, physical exercise preference, whether to followscheduled maintenance, a preference of merchant for a given service, andmerchant location preference. Consumer asset attributes arecharacteristics relating to assets of the consumer, for example, theconsumer's primary care doctor, spouse/partner, home address, andvehicle identification number. Consumer task attributes are propertiesassociated with tasks or services the consumer can request or purchase,such as car repair, car maintenance, doctor visits, exercise classes,training, haircuts, and spa appointments.

Merchant identification attributes specify identifying information abouta merchant, such as business name, service sector, business address,gender, business license, on time performance, operating hours, type ofpersonal care provider, type of automotive service provider, type ofbuilding maintenance provider, type of training provider, type oftransportation services provider, and type of healthcare provider.Merchant preference attributes represent a merchant's choices withrespect to various system settings, services, or other items. Forexample, merchant preference attributes can include: resourceutilization, accept weekend appointments, automatic appointment triage,accept emergency requests, accept insurance, and type of insuranceaccepted. Merchant resource attributes are characteristics relating tothe resources of the merchant, for example, employee names, employeespecialties, and current location. Merchant task attributes areproperties associated with tasks or services the merchant can provide,such as car repair, car maintenance, doctor visits, exercise classes,training, haircuts, and spa appointments.

Further, as a precursor to making a match between a consumer need and anavailable merchant service offering, the system can predict whether theconsumer is likely to even seek a particular service. For instance, ifthe system is provided data relating to vehicle maintenance records ofHonda Accord automobiles, it can “learn” that owners of this vehiclehave the oil changed approximately every 8,000 miles. Accordingly, thesystem can predict that an Accord owner that had an oil change 7,900miles ago will seek to make a maintenance appointment in the nearfuture, and it will automatically schedule the appointment with amerchant.

Implementations of the system can use appropriate hardware or software;for example, it can execute on a system capable of running an operatingsystem such as the Microsoft Windows® operating systems, the Apple OS X®operating systems, the Apple iOS® platform, the Google Android™platform, the Linux® operating system and other variants of UNIX®operating systems, and the like.

Some or all of the described functionality can be implemented insoftware and/or hardware on a customer or merchant's device. A customeror merchant device can include, but is not limited to, a smart phone,smart watch, smart glasses, tablet computer, portable computer,television, gaming device, music player, mobile telephone, laptop,palmtop, smart or dumb terminal, network computer, personal digitalassistant, wireless device, information appliance, workstation,minicomputer, mainframe computer, or other computing device, that isoperated as a general purpose computer or a special purpose hardwaredevice that can execute the functionality described herein. Thesoftware, for example, can be implemented on a general purpose computingdevice in the form of a computer including a processing unit, a systemmemory, and a system bus that couples various system componentsincluding the system memory to the processing unit.

Additionally or alternatively, some or all of the functionality can beperformed remotely, in the cloud, or via software-as-a-service. Forexample, matching functions can be performed on one or more remoteservers or other devices, as described above, that communicate with thecustomer and merchant devices. The remote functionality can execute onserver class computers that have sufficient memory, data storage, andprocessing power and that run a server class operating system (e.g.,Oracle® Solaris®, GNU/Linux®, and the Microsoft® Windows® family ofoperating systems).

The systems can include a plurality of software processing modulesstored in a memory and executed on a processor. By way of illustration,the program modules can be in the form of one or more suitableprogramming languages, which are converted to machine language or objectcode to allow the processor or processors to execute the instructions.The software can be in the form of a standalone application, implementedin a suitable programming language or framework.

Method steps of the techniques described herein can be performed by oneor more programmable processors executing one or more computer programsto perform functions by operating on input data and generating output.Method steps can also be performed by, and apparatus can be implementedas, special purpose logic circuitry, e.g., an FPGA (field programmablegate array) or an ASIC (application-specific integrated circuit).Modules can refer to portions of the computer program and/or theprocessor/special circuitry that implements that functionality.

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors.Generally, a processor will receive instructions and data from aread-only memory or a random access memory or both. The essentialelements of a computer are a processor for executing instructions andone or more memory devices for storing instructions and data.Information carriers suitable for embodying computer programinstructions and data include all forms of non-volatile memory,including by way of example semiconductor memory devices, e.g., EPROM,EEPROM, and flash memory devices; magnetic disks, e.g., internal harddisks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROMdisks. One or more memories can store media assets (e.g., audio, video,graphics, interface elements, and/or other media files), configurationfiles, and/or instructions that, when executed by a processor, form themodules, engines, and other components described herein and perform thefunctionality associated with the components. The processor and thememory can be supplemented by, or incorporated in special purpose logiccircuitry.

In various implementations, a customer and/or merchant device includes aweb browser, native application, or both, that facilitates execution ofthe functionality described herein. A web browser allows the device torequest a web page or other downloadable program, applet, or document(e.g., from the server(s)) with a web page request. One example of a webpage is a data file that includes computer executable or interpretableinformation, graphics, sound, text, and/or video, that can be displayed,executed, played, processed, streamed, and/or stored and that cancontain links, or pointers, to other web pages. In one implementation, auser of the device manually requests a web page from the server.Alternatively, the device automatically makes requests with the webbrowser. Examples of commercially available web browser software includeMicrosoft® Internet Explorer®, Mozilla® Firefox®, and Apple® Safari®.

In some implementations, the customer and/or merchant devices includeclient software. The client software provides functionality to thedevice that provides for the implementation and execution of thefeatures described herein. The client software can be implemented invarious forms, for example, it can be in the form of a nativeapplication, web page, widget, and/or Java, JavaScript, .Net,Silverlight, Flash, and/or other applet or plug-in that is downloaded tothe device and runs in conjunction with the web browser. The clientsoftware and the web browser can be part of a single client-serverinterface; for example, the client software can be implemented as aplug-in to the web browser or to another framework or operating system.Other suitable client software architecture, including but not limitedto widget frameworks and applet technology can also be employed with theclient software.

A communications network can connect the devices with one or moreservers and/or with each other. The communication can take place overmedia such as standard telephone lines, LAN or WAN links (e.g., T1, T3,56 kb, X.25), broadband connections (ISDN, Frame Relay, ATM), wirelesslinks (802.11 (Wi-Fi), Bluetooth, GSM, CDMA, etc.), for example. Othercommunication media are possible. The network can carry TCP/IP protocolcommunications, and HTTP/HTTPS requests made by a web browser, and theconnection between the clients and servers can be communicated over suchTCP/IP networks. Other communication protocols are possible.

The system can also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules can be located in both local and remotecomputer storage media including memory storage devices. Other types ofsystem hardware and software than that described herein can also beused, depending on the capacity of the device and the amount of requireddata processing capability. The system can also be implemented on one ormore virtual machines executing virtualized operating systems such asthose mentioned above, and that operate on one or more computers havinghardware such as that described herein.

In some cases, relational or other structured databases can provide suchfunctionality, for example, as a database management system which storesdata for processing. Examples of databases include the MySQL DatabaseServer or ORACLE Database Server offered by ORACLE Corp. of RedwoodShores, Calif., the PostgreSQL Database Server by the PostgreSQL GlobalDevelopment Group of Berkeley, Calif., or the DB2 Database Serveroffered by IBM.

Also, the instructions and/or data used in the practice of the systemsand methods herein can utilize compression or encryption technique oralgorithm. An encryption module can be used to encrypt data, and filesor other data can be decrypted using a suitable decryption module.

It should also be noted that implementations of the systems and methodscan be provided as one or more computer-readable programs embodied on orin one or more articles of manufacture. The program instructions can beencoded on an artificially-generated propagated signal, e.g., amachine-generated electrical, optical, or electromagnetic signal, thatis generated to encode information for transmission to suitable receiverapparatus for execution by a data processing apparatus. A computerstorage medium can be, or be included in, a computer-readable storagedevice, a computer-readable storage substrate, a random or serial accessmemory array or device, or a combination of one or more of them.Moreover, while a computer storage medium is not a propagated signal, acomputer storage medium can be a source or destination of computerprogram instructions encoded in an artificially-generated propagatedsignal. The computer storage medium can also be, or be included in, oneor more separate physical components or media (e.g., multiple CDs,disks, or other storage devices).

In one implementation, illustrated in FIG. 1, the central component ofthe system is the Marketplace Server 100, which can operate in a secureInternet cloud environment 110. The Marketplace Server 100, which can bedirectly coordinated with Memory 103 and Appointment Data 118, maintainsall merchant scheduling and all individual consumer scheduling, andstores all newly created, pending, and past appointment actions, e.g.,history, which is also referred to as learned or ongoing data. TheMarketplace Server 100 can implement the primary technology by whichautomated appointment requests from individual Customers 106-109 arematched with the Merchants 111-114 and by which appointmentconfirmations are coordinated and confirmed through the Merchants'111-114 and the Customers' 106-109 calendars automatically and withouthuman intervention. Although FIG. 1, depicts three separate hardwaredevices, the Seller Matching Engine 101, the Marketplace Server 100, andthe Buyer Matching Engine 102 can be implemented on a single hardwaredevice or multiple hardware devices. In this latter configuration,functions and separations can be maintained as though the devices areseparate.

In FIG. 1, Customer 106 depicts a customer who uses the system's userinterface through their smart phone, e.g., an Apple® iPhone® mobiledigital device, Customer 107 depicts a customer who accesses thesystem's user interface through their tablet computing device, e.g., anApple® iPad® mobile digital device, Customer 108 depicts a customer whouses the system's user interface through their portable laptop computer,e.g., an Apple® MacBook Pro® computer, and Customer 109 depicts acustomer who uses the system's user interface through their desktopcomputer, e.g., an Apple® Mac Pro® computer.

Merchant 111 depicts a merchant who uses the system's user interfacethrough their smart phone, e.g., an Apple® iPhone® mobile digitaldevice, Merchant 112 depicts a merchant who uses the system's userinterface through their tablet computing device, e.g., an Apple® iPad®mobile digital device, Merchant 113 depicts a merchant who uses thesystem's user interface through their portable laptop computer, e.g., anApple® MacBook Pro® computer, and Merchant 114 depicts a merchant whouses the system's user interface through their desktop computer, e.g.,an Apple® Mac Pro® computer.

In some implementations, the system can utilize a customized userinterface between the consumer and merchants and professionals.Advantageously, the system can be structured for only one user identitylog-in to reach the entire system instead of a separate log-in for eachmerchant or professional.

The Customers 106-109 and Merchants 111-114 connect to the systemthrough the Internet and wireless connections (e.g., Wi-Fi connections116) or dedicated Internet lines. Should a particular territory orconnection for a merchant or customer not have Wi-Fi or other wide bandInternet available, modem connections will also be a method in which toaccess the network.

The Buyer Matching Engine

Still referring to the implementation depicted in FIG. 1, a structurallyimportant element of the system is the Buyer Matching Engine 102, whichis directly and securely connected to the Marketplace Server 100. TheBuyer Matching Engine 102 operates as a filter between the individualConsumer 106-109 and the Marketplace Server 100. The Buyer MatchingEngine 102 can be adapted to filter service need requests from theConsumers 106-109 based on the individual details and data, preferences,history information, and other attributes that the Consumers 106-109enter and/or that is collected in the operations of the system.Transactions, preferences, and information regarding the customers aremaintained in the Memory 105, which is directly connected to the BuyerMatching Engine 102. The collection of preferences and customerattributes within the Memory 105 is a separately identified memorycomponent known as the Consumer Persona 119.

The various consumer attributes included in the Consumer Persona 119 caninclude, but are not necessarily limited to: identification attributessuch as base personal contact information, professional contactinformation, healthcare information, personal care information, andpayment information; asset attributes such as automotive information,e.g., the identity and the details of automobiles owned, buildingmaintenance information, e.g., details of all physical plant elements ofbuildings owned or the identity of the elements of the landscape formaintenance purposes, and other asset information regarding anindividual; and preference attributes such as preferences for “Ad Tag”words, settings and unique details for consumers, transaction history,relationships with existing merchants, e.g., how long they have beenusing a particular merchant, network services preferences, and so on.

For individuals/consumers, some examples of the various types ofattributes that the system stores can include, for the purpose ofillustration and not limitation, medical records, medical histories,prescription information, medical insurance information, preferredservice providers, car insurance information (for electronic interchangewhen needed and where updates are automatically made when they occur),property insurance information, personal information, e.g., billingaddress, mailing address, shipping address, business address, spouse,children, listing of all doctors (for medical emergencies where auniversal barcode can be used by an emergency crew or paramedic, in thecondition of the unconsciousness of the individual, to identify alldetails of the medical condition and where a photo of the individualwill help them ensure that the mobile device is being carried by theperson who is in need of medical care), and identification of allrelevant details regarding all cars and motorcycles owned (which can becross referenced to the auto insurance policy information).

The system can provide the individual consumer, or customer, in additionto other things, with the following: a task list of needed services,such as automated direct receipt of car maintenance needs (e.g., basedon the car's microchip noting that something is not functioning, or theneed for scheduled maintenance based on the car's mileage in relation tothe manufacturer's service schedule) and placing the need on a list forthe individual/consumer to either decide to authorize the system'sautomatic sourcing and scheduling of the work (based on the consumer'spreferences in their persona) or to place the work in a “hold” status;based on a consumer's persona preferences for attention to health andpersonal care services, automatic scheduling of doctor examinations orpreferred personal care needs, such as a monthly massage or an annualcheck-up examination; a task generation function that allows a consumerto add a desired service need, select the preference that is desired,e.g., the best price, the most convenient time, a time that convenientlyfits into a schedule gap, a preference for a particular merchant orprofessional. Advantageously, the system automatically schedules theneeded or desired service without intervention from the individual.

The system can also maintain all information and data regarding anindividual's service needs, service preferences, and histories toprovide for, for example, automatic scheduling of maintenance services(e.g., physical asset maintenance requirements, such as home heating andair conditioning systems and equipment), direct automated contact withservice providers when conditions occur which warrant attention, such asa recall on a car to address a defect, a need to visit a physician whena drug manufacturer cautions a physician about a prescription, automatedrequired forms updates prior to the time of a service appointment (e.g.,update of prescription information or the completion of standard medicalinformation forms before seeing a new doctor), automatic transmission ofasset details, such as a car, prior to the appointment with the serviceprovider so that the provider has the information in their electronicfiles and does not have to spend the time collecting and entering thisinformation at the time of the service, and industry standardization ofrequired forms so that all small-to-medium-sized business (SMB)merchants and professionals are assured that they are collecting what isneeded or prescribed by law.

The system can also be adapted to track, monitor, and notify of medicalconditions using the multitude of devices that exist to track suchthings as blood pressure. Should the data indicate an adverse trend anddepending on the individual's preference settings, it can automaticallynotify the person's appropriate doctor. This information can be trackedin the Consumer Persona 119 and be available for electronic release andform completion for a doctor visit.

The Seller Matching Engine

Similarly, the Seller Matching Engine 101 operates as a filtrationbetween the Merchant 111-114 and the Marketplace Server 100. Moreparticularly, the Seller Matching Engine 101 filters the serviceappointment activity and transactions from the Marketplace Server 100based on the a merchant's individual details and data, preferences, andhistory information. All transactions, preferences, and informationregarding the Merchants 111-114 can be maintained in the Memory 104 thatis directly attached to the Seller Matching Engine 101. The collectionof preferences and customer details within the Memory 104 is aseparately identified memory component known as the Merchant Profile117.

The various attributes in the Merchant Profile 117 can include, but arenot necessarily limited to, merchant identification attributes such asprimary business information, business locations, the services offered,the price list for the services; resource attributes such as thepersonnel and equipment that the business uses for the delivery of theservices they offer, the delivery layout for their locations, thestandard forms that the business uses, customer list, and all customerdetails that are relevant to service to these customers; and preferenceattributes such as payment preferences, settings and unique details,transaction history, relationships with existing customers/consumers,e.g., how long they have been a customer, and their network servicespreferences.

For merchants and professionals providing services, the Merchant Profile117 element of the system stores information relating to the varioustypes of merchant attributes, including but not limited to: standardform templates for disclosure to customers, insurance information (e.g.,for business and workers compensation), geographical locations,resources used for services (e.g., personnel, machines, equipment, goodstracked using standard UPC codes), price lists for services, customerhistory of prior services delivered, and customer lists with relevantdetails about the services that they use.

In a general sense, and in addition to a number of other combination ofservices and functions, the system can provide the merchant with thefollowing queuing functionalities, which are discussed in greater detailbelow: fully automated, real time scheduling, monitoring logistics,pricing and payment, automation of collection and dissemination ofneeded and required information, collecting and organizing informationwith “tags,” forms standardization, and the like.

Fully automated, real time scheduling can include, without limitation,receiving the request, analyzing the opportunity, scheduling theservice, confirming the appointment in a direct, automated connectionbetween the merchant's calendar and the customer's calendar, monitoringthe customer's calendar to ensure that the service delivery remains ontheir calendar and has not been replaced with another appointment thatis not related to the service (which can replace the current practice ofcustomer reminder calls, SMS text messaging or automated phone calls),sending appointment reminders in various formats, and sendingrequirements notifications and reminders (e.g., “no eating or drinkingafter 6:00 p.m. in the evening before”) when the appointment relates toa blood test or surgery where the results can be impacted if the fastingrequirement is not followed. Optionally, the system can be adapted tomonitor the conditions of a person's calendar or geographical locationto remind them of the “no eating or drinking” requirement when, forexample, they have a dinner appointment on their calendar or theirmobile device indicates that they have just entered a fast foodrestaurant location.

Monitoring logistics can include, without limitation, advising acustomer of a merchant's status relating to the appointment time (e.g.,are the merchants on time, running late or ahead of schedule),monitoring the proximity of the customer prior to the time of theservice appointment, triaging the service schedule of the merchant andre-prioritizing customers based on the customer's proximity as reportedby location-based tracking (if authorized by the customer in theirpreferences), and advising customers when work is completed.

Pricing and payment can include, without limitation, advising thecustomer of the cost of the service, offering optional pre-paymentdiscounts, collecting payment, and dynamic pricing tracking thatprovides the merchant with information regarding how many requests wereinitiated for a particular time. This information will allow themerchant to price time slots with more demand at higher prices and tooffer alternate time slots at lower prices to fill the work flow for themerchant's operating resources.

Automation of collection and dissemination of needed and requiredinformation can include, without limitation, collecting all neededhistory information from the customer without human intervention, andproviding customer with all standard disclosure information, e.g., termsof service and compliance with local laws.

Collecting and organizing information with “tags” can include, withoutlimitation, information needed for a consumer's or a merchant's taxreturns and tax advisor, information needed for a merchant's riskmanager or insurance broker, and information needed for paymentprocessing.

Forms standardization can include, without limitation, defining whatinformation and forms are industry standard and providing electronic,i.e., paperless, forms for all SMB merchants, which helps the merchantscomply with laws and standardizes the forms that consumers see frommerchant to merchant, and providing an electronic filing system for allinformation collection with an archive that is available to the merchantat any time regarding past services delivered.

The Consumer Persona

The Consumer Persona 119 can be structured as an archive and collectionof all relevant information (e.g., attributes) concerning a consumer.Consumers can choose to input everything about themselves or they canchoose to input less. The more that they input, the more helpful thatthe system can be to them. For example, in preparing to go to a personalphysician for an annual medical examination, and knowing that all of hermedical information is current in the Consumer Persona 119 throughupdates from other medical professionals, pharmacists, and other medicalservice providers, a particular patient can be assured that all of herrequired information will have been previously electronically deliveredto her physician and she will not have to complete the dreaded“clipboard” of documents. As a result, the consumer's annual examinationprocess is much more efficient and she is assured that all currentinformation is in the files of her personal physician before shearrives. Merchants or professionals also benefit when patientinformation is current, as it allows them to focus on their patients'care.

The Merchant Profile

The Merchant Profile Persona 117 is structured as an archive andcollection of all relevant information (e.g., attributes) concerning amerchant. Merchants can use this feature of the system to registerrelevant information in the marketplace. For example, a merchant candesire to input as much information about their business as they canbecause they know that it will allow the system's task acquisition,matching, and sourcing functionalities in the Marketplace Server 100 toreach as many customers and potential customers as possible. Consumershave automated access to information regarding a merchant and can use itto source or know that the system is automatically sourcing serviceopportunities on their behalf and in their best interests. For merchantsor professionals, the feature provides market presence and helps incustomer satisfaction and customer acquisition.

The Marketplace Server

At the core of the interrelated processing that forms the system is theMarketplace Server 100, which is connected with Appointment Data 118 andMemory 103. The Marketplace Server 100 has the primary function ofoperating an online marketplace for locally-delivered commerce services.Although there are a multitude of functions that comprise thisresponsibility, some of the primary duties include: originating andexecuting marketplace services transactions, matching buyer-side tradeoffers with seller-side bids, executing schedule transactions for bothconsumers and merchants, originating and executing confirmations andnotifications for transactions, and managing the proactive initiativesconcerning the calendars of both the consumer and the merchant.

A direct extension of the Marketplace Server 100 is the Appointment Data118 and Memory 103. In addition to managing the marketplace, thesedevices collectively maintain primary information. On behalf of both themerchant and the customer, they maintain the primary calendars, currentand live transaction flow, and history and transaction documents.

The learned data in the Marketplace Server 100 represent the collectionof knowledge from marketplace transactions. The type of knowledge isbroad and the combinations are unlimited. For example, the averageamount of time that a consumer who engages a car repair merchant for aproblem that is described generally as “2004 Cadillac Escalade won'tstart” can be matched with the actual data from repairs that havepreviously been made. The most common solutions/results can bedetermined and the actual times experienced used to estimate thecompletion time for this newly scheduled appointment. By doing so, thesystem is applying logic based on actual reported results from thesystem's community to assist a merchant and consumer to better managetime. This same logic can be applied, post service delivery, to thecosts charged to the consumer to help the consumer understand how hiscosts compared to others in the system's community who experienced thesame problem. Conversely, it can be applied to the merchant whodelivered the service to help him better understand how the timeincurred by his productive resources to address and resolve the problemcompared to other merchants similarly connected to the system'scommunity. This helps the merchants manage business operationscompetitively without sharing their own information and without learningthe information of their competitors, as the information can be sharedas an average of the community without revealing identities, or inanother anonymous fashion.

The User Interface

Both the Seller 101 and the Buyer Matching Engines 102 are therepresentatives of their constituencies of the merchant and theconsumer, respectively. As such, the system is structured to providecritical and primary connections between the interactions of themerchant and consumer, through their smart device or computer. On behalfof the consumer, the Buyer Matching Engine 102 is the primary filtrationand matching device and, as noted above, due to the type and amount ofconsumer preference, settings, and other attribute information that isstored in the connected Memory 105 and Consumer Persona 119, the BuyerMatching Engine 102 is a buyer agent that initiates and managesmarketplace services on behalf of the buyer. The reverse is true for theSeller Matching Engine 101 on behalf of the seller as this devicemaintains preference, settings, and other attribute information storedin Memory 104 and Merchant Profile 117 on behalf of the merchant sellersand is positioned in the system to be the seller's agent in theinitiation and management of all marketplace services transactions andin all scheduling transactions.

Facilitating these connections is the User Interface 120, shown in FIG.2. Regardless of the type of device the Customer 105-109 or the Merchant111-114 is using, the User Interface 120 of the system represents thewindow through which all connections pass. More specifically, the UserInterface 120 can be a dedicated interface screen that is unique andcustom designed for the system and for the devices through which theinformation is connected. Primary interfaces can be through thecustomer's calendar application, such as iCal, Outlook, Gmail and Yahoo!Calendar. The User Interface 120 can use the system's standard userinterface but connect with the noted third-party calendars. In someimplementations, the User Interface 120 includes graphical and/ortext-based elements. The User Interface 120 can also include a naturallanguage interface, through which a user types or speaks commands to thesystem, and through which natural language may be displayed and/orspoken in response.

The system is structured around a marketplace with integrated commerceservices. A marketplace (and all services and marketplace standards) isimportant because, even though one-on-one scheduling is possible, whenit is combined in a marketplace environment, it creates multiple serviceproviders and consumers and allows combinations of transactions that arenot possible in one-on-one environments. The integrated methods anddesign structure of the system simplify the manner in which buyers reachsellers and in which transactions are executed. The system alsoovercomes previous shortcomings because it factors in the dimension oftime and the logic of calendaring through algorithm formulas and usingthe population of ongoing data. As explained earlier in this document,the application of logic and time with marketplace experiences throughthe system's ongoing data creates an environment where the collectiveexperiences of all consumers and merchants in the marketplace can beused to instill efficiencies in the time usage of all other users.

Standard Marketplace Transaction Processes and Methods

The primary objective of a merchant who sells in a marketplace is toexpand the number of customers and increase revenues through customergrowth, customer satisfaction, and repeat business. Among the primarybenefits of the User Interface 120 is the design of a single log-in toreach the network, i.e., the marketplace. For consumers/users, thisdesign enables each and every one to reach all of the merchants on thenetwork and, of course, the reverse applies for merchants reachingcustomers.

Inasmuch as the network and marketplace design are focused on the saleof consumer services exclusively, the visual design of the UserInterface 120 is purposed for the sale of consumer services and thesteps and visual screens are consistent and intuitive for this type ofsale. The design of the system, whereby the merchants are part of amarket that is contained within a cloud network, enables the focusing ofsearching and sourcing for consumer services. When a consumer is seekinga service for scheduling, the search filters through the consumer'sBuyer Matching Engine 102, which links through the Consumer Persona 119and therefore applies the consumer's preference and setting attributesto the search. As a result, the system delivers search results that areextremely focused on what the consumer is seeking and filtered by whatthe consumer specifically prefers.

As an example, a particular consumer's preference attributes mightinclude “always select current service providers” or “always searchbased on the lowest price for the service.” In the first search, theresults would be limited to relationships that the consumer has and itcan be targeted whereby, for example, a particular merchant for aparticular car can be the result. In the second example, the searchresults can include existing relationships but only at the lowest price.This searching method of the system will result in the completefiltration of advertising placed by ad words, e.g., as used by Google,and the elimination of results that have no relationship to what theconsumer is seeking. There are endless permutations of how the system'sfiltration-based search delivers results that provide preference sortingand ranking, similarity linking and even such filtration as matchingsimilarly grouped items.

The system is designed to standardize service type descriptions forsimilar consumer services. This is accomplished as merchants set uptheir service catalogue in the Merchant Profile 117. This is alsoaccomplished through comparison as the system's marketplace executestransactions in services. With all of this information and data, thesystem consistently compares service descriptions for standardcategorization and links similar services for comparison purposes asconsumers search and source for service opportunities. Thestandardization that is used and issued by the system can be, forexample, a barcode that is included on the merchant's services list intheir Merchant Profile 117.

The system can be adapted to use the facility information and servicetype attributes in the Merchant Profile 117 to classify merchants bystandard codes. This functionality delivers an unbiased comparison andclassification of merchants based on their service offerings andfacility capabilities. The standard classification codes are publishedto enable consumers to compare merchants by standard service andcapability categories rather than biased marketing information releasedby the merchants themselves. The system can also include the catalogingof a standard forms library for disclosure by merchants with allcustomer transactions. For example, whenever a consumer uses spaservices for personal care or doctor services for health care, thecompletion of what is typically represented as standard forms isrequested. There is currently little, if any, consistency in thepopulation of forms for even the same service by different serviceproviders. Using the Forms Distribution functionality that isincorporated into the Marketplace Server 100, information that isresident in the Consumer Persona 119 can be sourced by the MarketplaceServer 100 and populated on the requisite forms that are dictated by themerchant and catalogued in Memory 103. In some or all cases, thecustomer and the merchant provide approval for the release of theinformation (either through a preference setting attribute in theirConsumer Persona 119 or their Merchant Profile 117, respectively).Advantageously, the standard forms population and distribution iscompleted electronically. e.g., “digitally,” with no paper distributionand no printing required. All forms population and distribution can bearchived in Memory 103, 104, and/or 105. This functionality results inthe standardization of consumer service terms, disclosures andconditions.

The system also can be configured to assign unique barcode identities toeach merchant member and each consumer member. The unique barcode isstored in each merchant's Merchant Profile 117 and each consumer'sConsumer Persona 119. The barcode is used for identity verification andfor check-in at a merchant's facility. For example, when an individualconsumer arrives at a merchant's facility, the consumer accesses theuser interface 17 from their smart phone device or their tabletcomputer. The barcode displays on the device's screen 18 and ispresented to a barcode scanner that is located at the merchant's site.Upon identification, the system registers the arrival on the MarketplaceServer 100 and, among other things, verifies the appointment and thestatus of the transaction. The barcode identity is also used for paymentprocessing as explained below. The barcode identity is assigned by thesystem when a merchant or an individual consumer joins the system'snetwork and registers for the marketplace.

Through the system's Direct Network Connection 115 and the automatednegotiation between the Buyer Matching Engine 102 and the SellerMatching Engine 101 on the Marketplace Server 100, service appointmentsare made and the confirmation is transmitted to all of the partiesinvolved. On both sides of the transaction, i.e., merchant and consumer,confirmation can be recorded in the Appointment Data 118, the MerchantMemory 104 and the Consumer Memory 105. Based on the preferences andsettings in the Consumer Persona 119, the appointment is entered intoeither the consumer's personal calendar that the system stores inAppointment Data 118 or, through the User Interface 110, the appointmentis directly interfaced with the individual consumer's personal calendar,such as iCal, Outlook, Google Calendar or Yahoo! Calendar.

The system also can be structured to enable merchants to updateconsumers on the status of a service electronically using the consumer'ssettings and preferences in their Consumer Persona 119, as filteredthrough the Buyer Matching Engine 102. Standard “pull-down” options areavailable to the merchant to update service status very quickly so thatthe consumer is consistently aware of the status of their work. Thissame functionality allows the merchant to notify consumers when, ascould happen with automobile repair, the applicable state law requiresthat the consumer be notified in advance to authorize additional workthat is discovered in the course of the original repair and that willexceed the original cost estimate. Moreover, using the information thatis electronically collected through the Internet Cloud Network 110, thesystem allows all merchants who use the system and who are registered onthe network marketplace to access the state-by-state,municipality-by-municipality, database of notification requirements thatare contained in the Appointment Data 118 memory that supplies theMarketplace Server 100. As a result of this functionality, the systemautomatically notifies all customers of additional costs and tracksapproval as required by the applicable laws in the location where theservice is being performed.

The system also can allow Customers 106 through 109 to set theirConsumer Persona 119 settings to track their current location, e.g.,accessible with mobile devices through a mobile network which usesinformation on the geographical position of the mobile device, to reportit to merchants where they have pending service without requiring a cellphone call. This functionality addresses law changes in which more andmore states are outlawing cell phone usage when operating an automobile.However, more importantly, it allows the merchant to triage theircustomer line-up so that one customer's tardiness does not create aservice delivery backlog that affects all customer's that follow.

Using the service catalogue and price list that the system maintains foreach merchant in their Merchant Profile 117 and Memory 104, the systemenables customers to pay for their service through the system's networkwithout requiring their locations to collect cash or to process creditcards. In addition, the system provides customers with guidanceregarding appropriate ranges for gratuities in certain service sectorswhere such practices are common. The gratuity settings can be set-up inthe Customer Persona 119 by each customer to enable tipping by industrystandard wherever payment is made with the system's in-network paymentor they can be set to request permission through the customer's mobiledevice whenever service is received and payment is being made. Becausethe in-network payment is processed by the system through themarketplace network, all merchants eliminate the risk of losses fromemployee theft or from accepting checks that are not backed withsufficient funds in the customer's bank account.

The system's Marketplace Server 100 provides all merchants and customerswith, in addition to universal access noted earlier, real-time access 24hours a day, which allows all merchants to access their customers at anytime for any customer to schedule an appointment without the necessityfor the merchant to be open for business. When appointments arescheduled after hours, the appointment confirmation is provided to allowboth parties to the transaction assurance that their appointment isscheduled and immediately appears on both calendars located in theAppointment Data 118.

The system is structured with the software application located on thesystem operator's Internet server (the Marketplace Server 100) and allcurrent merchant settings and data located on the Seller Matching Engine101, the Merchant Profile 117 and the Memory 104, as well as all currentcustomer settings located on the Buyer Matching Engine 102, the ConsumerPersona 119 and the Memory 105, all located on the system operator'sInternet hardware. As a result, neither the merchants nor the consumersare required to maintain computer hardware at their site. Also, accessto the system is available at any time without the necessity for themerchant or the consumer to have their computer or their mobile deviceturned on and connected to the Internet.

The system can enable any merchant or consumer to access it withouthaving to be connected to the Internet with a cable or without beinginside their own computer network. Indeed, anywhere where there is aWi-Fi router operating can provide access to the system. Also, thesystem's User Interface 120 is structured to allow full access for fullfunctionality from the software from anywhere where they can connect.

The system utilizes a profile structure that, as noted earlier, isorchestrated through a Seller Matching Engine 101 and a Buyer MatchingEngine 102. This structure allows all users of the network that powersthe marketplace to set their preferences and options in their respectivematching engine and use these settings for all of their consumerservices transactions without having to enter the same information foreach transaction that they complete. Also, the intelligence provided bythe matching engines allows merchants to seek new customers and allowscustomers to seek merchants. For example, if a particular customer istraveling from San Francisco to New York City and is interested in a spaservice during their stay in New York City, he can find spa serviceopportunities by merely listing a task item to find a service duringtheir trip. The system accesses their Consumer Persona 119 settingsthrough their Buyer Matching Engine 102 to seek the service through theMarketplace Server 100, which, in turn, seeks the merchant through theirMerchant Profile 117 through the Seller Matching Engine 101. If, in thisexample, the consumer wants the service for a particular price or duringa particular available time period (which the Buyer Matching Engine 102would access and track on behalf of the consumer and therefore be ableto use various time periods as noted in this consumer's Consumer Persona119), the Marketplace Server 100 would work to match the opportunitiesand schedule the service on behalf of both parties without the need forhuman intervention. With the system's design, all of this is completedfrom the mere preparation of a task list by the consumer which can evenbe done as easily as with voice access to a mobile computing device.Also, in this particular example, if the consumer's preference is toenjoy Starbucks coffee as noted in the Consumer Persona 119, theMarketplace Server 100 can offer suggestions to the customer oflocations near the delivery of the spa service for the consumer toconveniently stop for the beverage. In yet another example of thebenefit of the system's profile structure through profile filtration,the Marketplace Server 100 can use the intelligence gained from otherconsumers with the same profile as this particular consumer, e.g., age,health conditions or personal care preferences, to suggest other spaservices that people with similar profiles purchase in connection withthe original spa request, such as suggesting a pedicure following amassage.

The system can create “groups,” or sets of users associated with one ormore assets. Some or all members of a group can be provided withnotifications, schedule updates, tasks, and the like upon the occurrenceof an event associated with an asset. Groups may be created manually byusers, automatically by the system, or with partial automation (e.g.,the system suggests possible group configurations and users can confirm,add and/or remove the suggested group members and assets). Groups caninclude members that have some association with each other and/or withthe particular assets. For example, a set of related assets mightinclude personal property owned by a family, such as a car, atelevision, and a computer. The group members associated with the assetsmight include the family members, such as father, mother, son, anddaughter, but also an auto mechanic, television repairman, and computertechnician.

The daughter, for example, can use her iPad tablet to schedule a timeslot to watch a game show on the television, and other members of thefamily can be observe an asset schedule or automatically be notifiedthat the television will be in use during that time. If, prior to thegame show, the television breaks while the son is watching a movie, hecan use his smart phone to set an attribute associated with the asset(e.g., repair required=yes). Group members who have a connection to theasset can then be notified of the issue. The daughter can be alertedthat the TV is no longer functioning, and the appointment can becanceled and rescheduled automatically when the television is repaired.The television repairman can be notified that repair is necessary, therepair can be automatically added to the repairman's generated tasklist, and an appointment to service the television can be scheduled(with or without human intervention), using the techniques describedherein.

With the combined intelligence of all consumer members of the system'smarketplace and network, the Marketplace Server 100, for example, canutilize the service history of a particular merchant, such as anautomotive repair merchant, to suggest that they focus on a particularmanufacturer or model of car because there are many models of thatmanufacturer's car located near the service location of the merchant.This is significant to a merchant because, in this particular example, aparticular merchant can streamline their business and engage only theresources to service this particular need rather than attempting tospecialize in everything for all manufacturer's and models. For theconsumer, this is particularly helpful because automotive repair throughthe manufacturer's dealership is known to be more expensive andlocally-owned service facilities are known to be more cost effective.Yet, the consumer knows the least about the local service facilities andavoids the option. Knowing that a particular automotive merchantspecializes in their particular car and is more economically pricedallows the consumer to save money and still receive expert service.

The system can include the capability to collect feedback from consumersbased on their service experience, as noted below. Using the example inthe above section, the customer is able to use the system's structure ofservice price lists in the Merchant Profile 117 to compare service ratesfor the service that they are seeking to find the most economicallypriced option among the alternatives in their service area. They couldalternately source the merchant using feedback ratings if servicequality is more important to them than the best price.

The system can be designed with a network and marketplace structure toprotect the confidentiality of all of the members—both merchants andconsumers. For example, through universal confidentiality settings,customer information and history, as contained in the Consumer Persona119 and the Memory 105, cannot be shared with merchants, for example,for marketing purposes or for the sale of advertising. Also, throughuniversal confidentiality settings, merchant information, as containedin the Merchant Profile 117 and the Memory 104, cannot be shared withcompetitors of the merchant or with other merchants in general.

The system also can be designed to be administered through Internetcloud computing in a software-as-a-service (SaaS) environment as notedabove. As a result, merchants and consumers do not maintain separateInternet servers or hardware. The system is able to administer the bestand most up-do-date virus and spam protection on behalf of all membersand to protect the marketplace and the network. The costs to administerthis type of protection would be prohibitive for an individual merchantto maintain on their own hardware.

As noted previously, through the standardization of merchant disclosuresand consumer documents, all disclosures required by the merchant or theconsumer can be administered in a universal manner through the system'sMarketplace Server 100, which constantly monitors disclosurerequirements and employs standard disclosure forms using MerchantProfile 117 or Consumer Persona 119 information. In all cases, thedisclosures are archived for the protection of all parties.

The design of the software that comprises a portion of the systemenables confidential comparison analysis. For example, without knowingthe identity of the competitors being sourced (disclosure limited to thenumber of competitors and the market location), a merchant can determinehow a particular service offering is priced on their price list relativeto a particular market. If an automotive repair merchant wants to knowhow his price for wheel alignments compares to the market, it isavailable to him using market price intelligence in the MarketplaceServer 100. Similar comparisons are available to merchants for qualityfeedback and for any other standard factor metric that is available fortheir particular service sector. For the consumer, using the marketintelligence available in the Marketplace Server 100, and thestandardization of service types and standardization of merchantclassifications, the cost paid for a particular service can be comparedto what others in the network have paid (without disclosing the customernames or the merchant identities). This can be compared in themarketplace in which the service was delivered or with other markets inother locations. Also, merchants can use the same capability to comparevarious metrics regarding their business operations, such as theefficiency of their service resources, the utilization rates of theirservice personnel or their on-time percentage for service delivery. Thisfunctionality of the system provides the merchants with benchmarkingdata, based on the market intelligence information available from theMarketplace Server 100 and the Appointment Data 118. In all cases wherebenchmarking is provided, the confidentiality of the other merchants andconsumers in the survey is protected.

The system can also allow consumers who are members of the network andthe marketplace to compare their service purchases with others in theirlocation. This allows them to compare their lifestyle with others. Forexample, if other members in the marketplace are afflicted with the samemedical condition but experience lower healthcare costs than the memberwho is comparing, they can find out what benefits the other members. Ifother members experience orthopedic surgery and participate inrehabilitation for twelve weeks with no reoccurrence of the problem butthe member who is comparing determines that their rehabilitation'sduration was only six weeks, they can schedule the additional timeneeded with intelligence. For merchants, based on the customer marketintelligence that exists, they can determine the best location to placetheir service facility. For example, an audiologist can determine that aparticular location has a higher percentage of people with hearing aidsand know that opening an office in that location would offer a higherprobability of expanding their patient base. It would have the addedconsumer benefit of adding additional competition.

Using the market intelligence available through the Marketplace Server100 and the Appointment Data 118, a consumer can benchmark her servicepurchases against others based on any form of demographics orparticulars that exist. For example, a consumer can find that sheschedules oil changes for her cars less frequently than others, or shevisits her dentist for hygiene less frequently than others. Knowledge ofboth habit benchmarks provides an indication of issues that can causeproblems for the consumer, e.g., car failure or higher dental costs forrestoration work.

The Programming Elements

The network services element of the system provides specific benefits toconsumers and merchants. There are also elements of the system thatprovide benefits to the users that have a more global impact or inherentdesign. Many of these benefits relate to the knowledge gained from userexperiences and user activities. Also, these benefits relate directly tothe logic of calendaring and matching in a marketplace environment andall are affected by the dimension of time.

As an example, a merchant that operates an automotive repair businesscan schedule service for his customer's vehicles but can encounter manynormal circumstances that render his ability to predict the serviceduration difficult, if not impossible. Normal circumstances include, butare not limited to, difficulty in determining the cause of the problem,difficulty accessing the areas of the vehicle that need the repair,unfamiliarity with the particular vehicle, inexperience of the assignedrepair resource, and the identification of additional issues that mustbe addressed. All are typical situations. Each contributes to the timedimension and each either engages or creates calendaring logic that ishelpful. In this particular example, the merchant or, more specifically,the system, can collect this information as experience to be used onother customer's repairs. Merchants can record experience data in anorganized manner, such as a work log or service ledger but, more likely,it is just retained in the memory of the repair resource and/or thebusiness owner. This particular type of information is not a competitivebusiness (trade) secret or some form of proprietary information that isowned by that particular merchant. Even if the merchant considered itsomething that is a competitive secret, the merchant would have to buildhis business around performing this exact type of work repetitively inorder to capture the benefits from the knowledge. But that is typicallyillogical since the service is their product and not the procedure. Thisinformation can help the automotive service industry as a whole withoutcompromising a particular individual business, including the businessthat contributes the information.

Another example involves a medical practice that is operated by a groupof physicians. Every day the physicians schedule their time to addressthe needs of their patients. Their profession is known to require longwaiting room time and, as noted earlier, they experience a very high “noshow” rate in spite of efforts to address the root cause. Ideally, theoccurrence of patients not showing up for appointments should beeliminated. In many situations, medical service providers have to spendadditional time with patients to understand the complete symptoms of theissues they are encountering so that they can accurately diagnose theproblem, or, perhaps diagnose additional problems. In the course of herday, each of the doctors in this medical practice encounters just aboutevery circumstance that causes her schedule to be disarrayed. The resultcan be unhappy patients and schedule inaccuracies, which are issues thataffect patient relationships. If this particular practice issophisticated, the physicians can collect the knowledge of theirscheduling experiences and develop scheduling logic algorithms to applyto their calendar planning to improve their performance.

Some of the simplest matching activities performed by the system aremostly based on the process of finding the best match between merchantand consumer at a mutually acceptable time based on the ranking of thesimplest variables as defined by the consumer, e.g., price, quality andlocation being prime examples. Initially, consumers and merchants willhave entered only base data into the system, such as name and address.As their usage advances, consumers begin to enter preferences, e.g.,favorite service providers and types of services, and merchants begin toenter more detail, e.g., type of services offered and a price list.

Some appointments are more complex in both time and delivery. Forexample, an automotive repair can have a basic definition of theproblem, e.g., “the car will not start,” but the causes of the problemare many and varied. The procedures required for delivery and therelated time are more complex in terms of logic and predictability.Also, such appointments as an initial chiropractor exam where theproblem is noted as simple as “sore back” do not provide enoughinformation to assess the estimated amount of time.

Additional logic complexities can include location and third-partyrequirements. For example, if the appointment is for an initial visitwith a new doctor, the amount of information required by the patient'sinsurance company will typically be significant and much more elaboratethan what will be required for visits to existing doctor relationshipswhere the information will be limited to updates only. Also, serviceappointments such as appliance repair could require the sourcing ofspecific parts which are not known when the merchant initiates theservice appointment. As an even more complex scheduling example, if theservice involves house painting as part of home maintenance, and even ifthe merchant knows the supplies and tools needed, they do not know allsituations they will encounter is performing the work and thus thedimension of time is very unpredictable.

To effectively accomplish the objectives of the constituents and toapply the methodology of the system, algorithms can be used that rely onthe largest population of generic data. For example, when a serviceappointment is based on something as general as “the 2004 CadillacEscalade does not start”, the algorithms will factor in large amounts oflearned data related to similar descriptions of work, i.e., “does notstart,” and will factor in more data, such as, repair data of 2004Cadillac Escalades, repair data for 2004 Cadillacs, and repair datarelated to 2004 Cadillac Escalades with the same mileage as theparticular car scheduled for repair. The volume of learned data/ongoingdata that the system will use in the algorithm will be based on theservice and as many details as are available.

All of the elements of the system, including the consumer and merchantdata, the hardware and software components, the network structure, themethods and the procedures, are all structured around technologies thatcreate a marketplace and provide a trading exchange for network servicesthat merchants and consumers use. Also, the system utilizes thealgorithms behind the logic of calendaring and the dimension of time ina number of ways that support the system's matching methods and themarketplace. The marketplace is linked to the Internet through advanceprogramming interfaces that intensify the impact and effect of thesystem and the results achieved by all consumers and merchants who useit.

The Marketplace and Marketplace Standards

A core structural element of the system, and something that is supportedby other components, methods, and processes created by the system, isthe marketplace. Each part of the system is structured for the operationof a marketplace for merchants or professionals to offer their services,for consumers to source and engage the best possible merchants orprofessionals based on their individual criteria, and for consumerservice transactions to be processed and intensified by a rich networkservices infrastructure. As such, the marketplace is an electroniconline marketplace and, based on the design of the system, is able tooperate in an Internet cloud structure which allows SMB's to participatein the most technologically advanced structure without imposingsignificant costs and support burdens on their small operations. Also,large franchisors and manufacturers with a broad network of eitherindependently-owned or locally-managed consumer service operations areable to similarly participate in the consumer service marketplaceprovided by the system without cost and support roadblocks.

The Interface Layer/Advance Programming Interfaces (API)

The system includes many methods to accomplish the complex tasksinvolved in matching for services commerce as are described throughoutthis document. These methods engage many network services that areavailable for all constituents of the system's marketplace. In oneimplementation, the system includes an interface layer, which containsall of the necessary advance programming interfaces (APIs) tocommunicate with third-part mobile and desktop applications. Many ofthese applications provide information and data that the system'salgorithms utilize to trigger events, matches, and transactions. Thetasks and objectives that are accomplished with this API layer caninclude, without limitation: communicating, maintaining, linking,processing, comparing, tracking, and accomplishing.

Communicating can refer to providing information to mobile and desktopcommunication applications to achieve the notification and communicationobjectives of the system. Maintaining can refer to collecting andproviding information used by the system and the algorithms to monitorneeds, assign tasks, source resources and many other activities andactions related to maintaining assets and consumer services. Linking canrefer to collecting and providing information regarding third-partynotifications. Processing can refer to providing third-party servicesthat are preferred by the consumers and merchants, such as payment, andproviding third-party functionality that is exclusively connected withthe system, e.g., for such things as signature and document archive.Comparing can refer to providing and collecting feedback information andservice and customer ratings. Tracking can refer to providing two-waylocation based information and service delivery status. Accomplishingcan refer to managing task lists through proactive generation andmanagement of results.

The API layer can be structured to accommodate the particular needs ofthe constituents of the marketplace created by the system. The systemprovides many methods and processes that help the consumer and merchantsor professionals achieve their consumer service objectives. In thetechnology landscape in which the system is designed to operate, thereare many technologies that are used as a component of parts of theconsumption and service business processes. To capitalize on theinformation that is available through, or that can be provided tosupport, these technologies, the API interface layer is integrated anddesigned to accommodate the available data flow.

There are many examples of how the API layer can be engaged. In oneparticular example, a consumer who owns a General Motors automobile andhas subscribed to General Motor's “OnStar” service will have mileage andoperational status information collected regularly. Through the APIlayer, the system can be provided with this information so that actionscan be proactively taken. Indeed, the OnStar service does not functionas a marketplace with the matching technology of the system and cannotproactively schedule the remedial actions that can be needed. However,if General Motors requires a recall service for a particular model ofvehicle that is owned by one of the system's consumers, this notice,when sourced though OnStar, can be interfaced with the system and theremedial actions will be initiated on behalf of the consumer and with alink to the merchant, e.g., a General Motors dealer.

System Queuing Functionalities

The system creates a marketplace for locally-delivered consumer servicesby allowing access to endless buyers and sellers to complete the basictransaction of finding sources for consumer services and scheduling thetime in a directly connected, real-time, design. However, the system maynot directly purchase the time or otherwise inventory the operatingresources or services available for sale of the merchants whoparticipate in the network and execute transactions on the marketplaceexchange. Rather, as a marketplace exchange (or Internet platform), thesystem offers cloud based, network services that facilitate theestablishment of consumer and merchant relationships and supportexisting relationships. The design of the system can enable any of thefollowing network services to those merchants and customers who executetransactions through the Marketplace Server 100.

Auto-Match

Using the preferences in the Consumer Persona 119 and the MerchantProfile 117, the Marketplace Server 100 can be adapted, e.g., by usingthe Buyer Matching Engine 102 and the Seller Matching Engine 101, tocompare preferences between a consumer's profile and a merchant'sservice offerings. If all of the preferences for each party match, anappointment can be automatically scheduled through the MarketplaceServer 100 at mutually convenient times. For example, if a particularconsumer is seeking a haircut appointment during a business trip to NewYork City during a time window between 4:00 p.m. and 6:00 p.m. on aparticular day; at a location that is within two blocks of his hotel,where the barber or stylist is rated 4 or higher on a 5-point scale; andwhere the price does not exceed $50, the appointment can beautomatically scheduled with a merchant or professional with whom all ofthese criteria match completely or substantially (e.g., greater than adefined threshold). Advantageously, the consumer's needs are proactivelymanaged and the information from various merchants is reviewed by thesystem without the involvement of the consumer. Moreover, if a completematch of details is achieved, the consumer achieves his schedulingobjective with extremely limited involvement (by only setting theobjectives and the preferences). At the merchant or professional end, acustomer engagement is automatically scheduled and their business isexpanded by an opportunity which they would not otherwise know about.

Option-Match

Similar to Auto-Match, using the preferences in the Consumer Persona 119and the Merchant Profile 117, the Marketplace Server 100 can be adaptedto use the Buyer Matching Engine 102 and the Seller Matching Engine 101to compare preferences between a consumer's profile and a merchant'sservice offerings. Recognizing that not all of the preferences canmatch, the system can notify the consumer of a possible opportunity forthe appointment with the matched and unmatched preferences highlighted.The consumer can then make a decision and advise the system how toproceed, with the Marketplace Server 100 responding accordingly. Forexample, using the haircut example above, assume that all of the detailsmatch, except the appointment time is at 7:00 p.m. In this instance, theconsumer can accept or decline the non-conforming time slot.

Advantageously, as with Auto-Match, the consumer's needs are proactivelymanaged and the system reviews information from various merchantswithout the involvement of the consumer. Close or substantial matchesare highlighted of which the consumer is notified and the consumer canfollow-up or not. For merchants or professionals, prospective customerscan seek them out based on the Merchant Profile 117 without any actionby the merchant or professional. Furthermore, their business is marketedthrough the network service in the marketplace.

Predictive Matching

In some implementations, the matching functionality (e.g., automaticmatch, option match, and/or manual match) incorporates predictiveelements using learned data, as described above. Referring to FIG. 3,the Buyer Matching Engine 102 can predict (using, e.g., machinelearning, pattern matching, trained classifiers, and/or other techniquessuch as those described herein) that a customer is likely to request aservice (e.g., car repair, car maintenance, doctor visit, exerciseclass, training, haircut, spa appointment, etc.) based on historicaldata relating to the attributes of different customers that havepreviously requested that service (Step 301). To provide a reasonablyaccurate prediction, a classifier of the system will have been trainedto predict whether a given customer would request the service using thehistorical data. These customer attributes can include identificationattributes (e.g., name, gender, driver's license number, social securitynumber, no-show performance, and home address), preference attributes(e.g., level of feedback expected from merchants, type of service,whether to automatically schedule appointments for services, whether toallow another user to purchase an appointment, physical exercisepreference, whether to follow scheduled maintenance, a preference ofmerchant for a given service, and merchant location preference), assetattributes (e.g., primary care doctor, spouse/partner, home address, andvehicle identification number), and/or task attributes (e.g., carrepair, car maintenance, doctor visit, exercise class, training,haircut, and spa appointment). The relevant attributes of the customerare then input to the classifier, and the prediction is obtained asoutput.

For instance, referring back to the haircut example above, the systemcan reference attributes in the customer's Consumer Persona 119 andAppointment Data 118 (e.g., gender, age, when the customer's lasthaircut was), evaluate the customer's attributes in conjunction withlearned data based on attributes of other customers stored in the system(e.g., customers of same gender, of similar age, historical frequency ofhaircut), and determine that the customer is likely to request a haircutappointment in the near future.

The Seller Matching Engine 101 can predict (using, e.g., machinelearning, pattern matching, trained classifiers, and/or other techniquessuch as those described herein) which merchants meet a thresholdprobability of being selected by the customer to provide the service(e.g., more than 50% likely, more than 70% likely, more than 90% likely,etc.) (Step 303). Similarly to the customer request prediction describedabove, the merchant selection prediction can be based on historical datarelating to the attributes of different merchants that have previouslyprovided the particular service. To provide a reasonably accurateprediction, a classifier of the system will have been trained to predictwhether a given merchant would be selected to provide the service usingthe historical data. Merchant attributes can include identificationattributes (e.g., business name, service sector, business address,gender, business license, on time performance, operating hours, type ofpersonal care provider, type of automotive service provider, type ofbuilding maintenance provider, type of training provider, type oftransportation services provider, and type of healthcare provider),preference attributes (e.g., resource utilization, accept weekendappointments, automatic appointment triage, accept emergency requests,accept insurance, type of insurance accepted), resource attributes(e.g., employee name, employee specialty, and current location), and/ortask attributes (e.g., car repair, car maintenance, doctor visit,exercise class, haircut, and spa appointment). The relevant attributesof a merchant are then input to the classifier, and the prediction withrespect to that particular merchant is obtained as output.

For the haircut example, attributes in the Merchant Profile 117 can beexamined (e.g., merchant location, price list, services offered) andcompared to learned data based on attributes of other merchants storedin the system (e.g., services offered, customer base). Given what isknown about the customer, the learned data on merchants and/or othercustomers allows the system to predict whether the customer is likely toselect a particular merchant for scheduling his haircut appointment.

Following the merchant prediction described above, a merchant isselected (with or without manual user input) based on one or morecriteria (Step 305). The criteria can include, but are not limited to,the distance between the current location of the customer device and themerchant, the merchant's customer approval rating, a customerpreference, customer feedback regarding the merchant, and a specialty ofthe merchant. The Marketplace Server 100 then schedules an appointmentfor the service on the customer's calendar and the merchant's calendarin Appointment Data 118 (Step 307), and sends notifications (e.g.,audio, visual, haptic notifications) and/or other information regardingthe appointment to the customer's device and the merchant's device(e.g., smart phone, smart watch, smart glasses, portable computer,tablet computer, and the like) to notify the customer and merchant ofthe appointment. (Step 309).

After providing notification information to the customer's device, thesystem waits to receive an indication that the appointment has beenaccepted (e.g., the customer can press an “Accept” button shown in theUser Interface 120 on the customer's device, which notifies the systemof the acceptance) (Step 311). The appointment can also be automaticallyaccepted on behalf of the customer if, for example, it meets thecustomer's desired time frame, location, merchant rating, and/or otherpreference attributes. Accordingly, the customer can automatically ormanually accept the appointment as suggested by the Marketplace Server100. Alternatively, the customer can fully decline the appointment(e.g., haircut not needed at this time) (Option 311 a); decline to usethe suggested merchant (a different merchant can then be suggested)(Option 311 b); or decline the suggested appointment time or date (adifferent appointment time/date can then be suggested to the parties)(Option 311 c). As with acceptance of the appointment, the appointmentcan be automatically declined on the customer's behalf, for any of theabove reasons or another reason, based on the customer's preferenceattributes. The selected merchant (and/or a different merchant) can benotified with updates to the proposed appointment based on thecustomer's actions.

Before, after, or simultaneously with awaiting customer acceptance ofthe appointment, the system waits to receive an indication that theappointment has been accepted by the merchant (Step 313). The merchantcan accept the appointment as suggested by the Marketplace Server 100.Alternatively, the merchant can fully decline to provide the service tothe customer (in which case a different merchant can be suggested to thecustomer) (Option 313 a); or decline the suggested appointment time ordate (a different appointment time/date can then be suggested to theparties) (Option 313 b). The customer can be notified with updates tothe proposed appointment based on the merchant's actions. Once thecustomer and merchant acceptances have been received by the system, theappointment is considered confirmed (Step 315).

In one implementation, the Marketplace Server 100 predicts, based onlearned data, that forms are likely to be required for the service.Similar to the above, the prediction can be based on historical datarelating to the attributes of different merchants that have previouslyprovided the service and the attributes of different customers that havepreviously requested the service. For example, assume that a merchantthat provides hair cutting service requires new customers to fill out asurvey. Over time, the Marketplace Server 100 can learn the existence ofthis requirement if, for example, each time a customer has anappointment there for the first time, the merchant uploads a survey formwith the customer's responses to the system (and this data issubsequently used to train a classifier). Accordingly, when a newcustomer is scheduled for a haircutting appointment with the merchant(and this information is input to the classifier), the MarketplaceServer 100 can predict that the customer will need to fill out thesurvey and provide access to the appropriate form to the customer inadvance of the appointment, thus easing the merchant's intake processand saving the customer's valuable time.

Appointment Triage

In another implementation, the system continuously or periodicallymonitors the waiting area status and the arrival status of upcomingcustomers, and can be configured to offer triage suggestions to themerchant (or automatically triages, at the option of the merchant). Forexample, a doctor's office sets the system on automatic, which allowsthe system to triage patient flow based on which patients have arrived,when others are expected to arrive (e.g., as estimated by Track andLocate, described below), and who has canceled. The system then modifiesthe patient flow to maximize the on-time performance. For consumers,waiting room time is minimized and satisfaction is increased. Formerchants or professionals, the practice is managed efficiently andcustomers or patients achieve a higher level of satisfaction.

FIG. 4 illustrates one exemplary method for appointment triaging usingthe present system. At Step 401, the Marketplace Server 100 referencesAppointment Data 118 to identify an appointment for a service that isscheduled on the calendars of a customer and merchant. For example, acustomer might have an 3:00 pm appointment for a tune-up at a quick lubeshop in Boston. The system communicates with the customer's device(e.g., a smart phone, a smart watch, smart glasses, a portable computer,a tablet computer, etc.) in order to monitor its location for a periodof time before the appointment (e.g., 5 minutes before, 15 minutesbefore, 30 minutes before, 1 hour before, 3 hours before, and so on)(Step 403). Based on the current time (as applicable to the time zone ofthe customer and/or merchant), the current location of the customerdevice, and the location of the merchant, the Marketplace Server 100estimates when the customer will arrive at the merchant's location (Step405). This determination can be based on distance, driving conditions(e.g., traffic), weather, estimated speed, and other parameters relevantto estimating an arrival time. If the system determines that thecustomer will be late based on the estimated arrival time (Step 407), anaction can be taken with respect to the customer's appointment. Whethera customer is “late” can depend on preference attributes of themerchant; for example, the merchant can accept scheduled customers up to5 minutes past the scheduled appointment time, 10 minutes past, and soon, or there can be no tolerance for late arrivals at all.

Once it is determined that the customer will be late, the MarketplaceServer 100 can change the appointment on the calendars of the customerand merchant (with or without intervention on behalf of the merchantand/or customer) to accommodate the customer's estimated time of arrivalat the location of the merchant. Customer and/or merchant preferenceattributes, as well as the availability of either party, can determinewhether an appointment can be automatically rescheduled. For example, ifthe tune-up customer's device is detected to be approximately 45 minutesaway from Boston at 2:45 pm, the customer and merchant have calendaravailability, and both parties have a preference setting that allowsautomatic rescheduling, then the Marketplace Server 100 canautomatically reschedule the appointment for 3:30 pm.

In some implementations, prior to rescheduling the appointment, theMarketplace Server 100 provides notification of the need for anappointment change to the customer's device and the merchant's device(Step 409). As mentioned above, depending on the preference settings ofthe parties, the determination of whether rescheduling is possible oreven permitted (Step 411) can be performed automatically by theMarketplace Server 100, or can require decisions by the merchant and/orcustomer (e.g., the customer and/or merchant can be given the choice toreschedule or cancel the appointment). If it is determined that theappointment cannot or will not be rescheduled, the appointment iscanceled (Step 413) and removed from the calendars of the merchant andcustomer. On the other hand, if the appointment can be rescheduled, theMarketplace Server 100 provides the merchant and customer with arescheduled appointment time (Step 413). The system then awaits for themerchant and customer to accept the proposed change (eitherautomatically or manually) via their respective devices (Steps 415 and417). If either or both do not accept the rescheduled appointment, thesystem can reattempt to determine whether a reschedule is possible and,if so, propose a different time/date.

When (and if) the merchant and customer accept a proposed rescheduledappointment, the appointment is considered successfully rescheduled(Step 429). In some instances, the system can “make room” for a proposedrescheduled appointment by attempting to exchange the appointment timeslot with the appointment time slot of another customer having adifferent appointment time. In such a case, an additional consent isrequired for the appointment to be successfully rescheduled; namely,that of the other customer. Accordingly, if the Marketplace Server 100determines that there is a suitable appointment for exchange (Step 419),the late customer and the other customer having that appointment arenotified, via their respective customer devices, of the possibility ofexchanging appointments (Step 421), and the system awaits that othercustomer's acceptance (Step 423). In some cases, consent for an exchangeis also required from the late customer.

Continuing the above example, if another customer is currently scheduledfor the 3:30 pm tune-up time slot, but that customer's device isdetermined to be only 10 minutes away from the quick lube shop at 2:45pm, then the Marketplace Server 100 can determine that that othercustomer's appointment slot is suitable for exchange with the latecustomer (assuming both are 30-minute time slots). If all necessaryparties accept the proposed exchange, the late customer will rescheduledto 3:30 pm, and the other customer will be able to get in earlier, at3:00 pm.

If the other customer accepts the appointment exchange, the othercustomer can be rewarded; e.g., the other customer can be credited witha discount usable for the merchant's service, redeemable points forother services, a partial or full refund on the merchant's service, orother suitable reward (Step 425). Likewise, the late-arriving customercan be penalized by, e.g., charging the late customer a penalty fee,adding a surcharge onto the cost of the service, debiting an accountheld with the system, or other suitable penalty (Step 427). The latecustomer can be penalized for a late arrival, cancellation, and/orrescheduled appointment, regardless of whether an appointment exchangewith another customer is necessary.

It is to be appreciated that, although the above feature is describedwith respect to rescheduling late arrivals, the system is equallycapable of considering early arrivals, and can reschedule appointmentsin accordance with the above-described techniques.

Time Exchange

Time Exchange operates on the Marketplace Server 100 using theAppointment Data 118 for certified confirmed, pending appointments. Forexample, the system's functionality and design allow an individual witha need for an appointment at a particular time with a particularmerchant or professional to purchase the time from the individual who iscertified as the owner of the confirmed time. The system functions as atrading exchange to facilitate the connection between the offeror andthe certified owner of the appointment time.

FIG. 5 depicts an exemplary method for performing appointment exchangeusing the present system. At Step 501, the system receives a request topurchase a service appointment from a user of the system's device (e.g.,a smart phone, a smart watch, smart glasses, a portable computer, atablet computer, etc.). Based on the request, the Marketplace Server 100identifies one or more customers that have confirmed appointments forthe desired service (i.e., the appointments are scheduled on therespective merchants' and customers' calendars) (Step 503). TheMarketplace Server 100 then analyzes the list of identified customershaving confirmed appointments based on various criteria in order toidentify which appointments might be suitable for purchase by therequesting customer (Step 505). The criteria used can include, but arenot limited to, the distance between the requesting customer and themerchant, a customer approval rating of the merchant, the preferred timeor time range for the appointment, the request customer's preferences,customer feedback regarding the merchant, a specialty of the merchant,and whether the merchant would have access to information from thecustomer's prior appointments (if any) for the desired service or arelated service.

In some implementations, the criteria for determining suitableappointments for exchange can include predictions that the requestinguser would likely select one or more particular merchants to provide thedesired service. As previously described herein, such predictions can bemade based on historical data gathered by the system over time and usedto train a classifier. Relevant attributes of the customer and differentmerchants can then be input to the classifier in order to obtain thepredictions as output.

If suitable appointments are identified, the appointments can bedisplayed to the user (e.g., via a user interface on the user's device),and the user can select a desired appointment for purchase. Theappointment selection is then received at the system from the user'sdevice (Step 507). Minimal information about the identified appointmentscan be provided to the user (e.g., merchant, time, date) to protect theprivacy of the customers that are scheduled for those appointments.Thus, without knowing the name of the certified owner of an identifiedappointment, the system acts as a conduit to allow the requesting userto make an offer to the certified owner (via that owner's device)requesting that the owner sell the selected appointment to the user(Step 509).

The certified owner can accept or reject the offer, or make acounter-offer (Step 511). The transaction can continue until either amutual agreement has been made or both parties have rejected the otherparty's last offer. If the parties come to an agreement on the sale ofthe selected appointment, the Marketplace Server 100 removes theappointment from the calendar of the certified owner (Step 513) and addsthe appointment to the calendar of the requesting user (Step 515). Thecalendar of the merchant associated with the purchased appointment isalso updated to reflect that the appointment is now with the requestinguser (Step 517). Further, the requesting user is debited for the amounthe agreed to pay to the certified owner (Step 519), and the certifiedowner is credited for the agreed amount (Step 521). In someimplementations, a transaction fee can be also charged. The purchase isthen considered complete (Step 523). Additionally, the former owner ofthe appointment can have their appointment rescheduled with anothermerchant, for another date and time, etc. (with or without manualintervention), based on the attributes of the former owner and merchantsthat provide the service. The appointment of the former owner can berescheduled using any of the techniques described herein.

When the transactions involve an appointment with a professional, suchas a doctor, where insurance requirements have to be met or where otherarrangements have to be satisfied, the system can use the MerchantProfile 117 and the Consumer Persona 119 to verify the information, suchas an existing doctor/patient relationship between the requesting userand the doctor. When the offer process results in an agreement, thecertified appointment time is transferred from the certified owner tothe offeror and the appointment time is certified with the offeror. Thenegotiated payment is transferred through the network created by thesystem using the payment functionality. The previous certified owner canalso be offered another appointment time through the Marketplace Server100 with the same or a different merchant providing the service.

A prime example of the use of this network service would be for aconsumer with a critical need for a particular appointment time from aparticular merchant or professional where the time slot is notavailable. Sellers receive value for something they control at a timethat is not critical to them and are able to reschedule another timewith the merchant or professional. Buyers obtain a certified appointmentin a priority time slot that is critical to them. They are able tosatisfy both customers without getting involved and retain the servicerevenue from both rather than losing one to another service provider whohas the time available.

Bilateral Feedback

The system further discloses a method for facilitating a commercialtransaction between a user and a merchant. As described in connectionwith the system, in some implementations, the method can be practiced bya processing device(s) that can be adapted to executecomputer-executable instructions that are stored in a memory(ies). Forthe purpose of this disclosure, facilitating a commercial transaction byestablishing bilateral communication between a user and a specificmerchant, e.g., a merchant, will be described in the context of the userhaving received unsatisfactory or non-conforming services from themerchant. Those of ordinary skill in the art, however, can appreciatethat the methods and systems described herein can be applied to a myriadof other situations during which it would be advantageous to establishbi-lateral communication between the two parties to the commercialtransaction.

When negative feedback is received, the system's Bilateral Feedbackfunctionality provides notification to the merchant for a specifiedperiod of time. If the merchant chooses to address the feedback they cando so and make an offer to the customer for resolution. For example,assume a particular customer has had a negative experience with amerchant and accordingly issues negative feedback. Before publication onthe marketplace, the merchant receives it and can contact the customerwith an offer to resolve the problem. After resolving the customer'sissue, the customer can modify the feedback to reflect his satisfactionwith the resolution. Using this feature, the consumer benefits by havingnon-conforming services addressed, and merchants or professionalsbenefit by having an opportunity to correct adverse situations beforenegative feedback is released to others in the marketplace.

Referring to FIG. 6, a dissatisfied customer can initially prepare andtransmit via a communication network a report, e.g., for servicesreceived during a previously scheduled appointment, that can be adverseto the merchant rendering those services. The format of the report canvary wildly, e.g., the report can include a written, free-style portionas well as pre-designated ratings, e.g. numerical ratings such as 1 to 5or verbal ratings such as “dissatisfied”, “very dissatisfied”, and soforth. Such report formats and reporting systems are well-known to theart and will not be described in detail. Upon obtaining the customer'sreport (Step 601) and identifying the report as potentially adverse to aspecific merchant, the Marketplace Server 100 can predict that aparticular solution meets a threshold probability of resolving thecustomer's issue (Step 603). More specifically, the system can train aclassifier to predict whether a given solution will resolve an issueusing historical data relating to the service, the attributes ofdifferent customers that were satisfied by the solution, and/or theattributes of the merchant. Then, the attributes of the dissatisfiedcustomer are used as input to the classifier, and the predictedsolution(s) is obtained as output. A predicted solution can be, forexample, a discount, full or partial refund, repair or replacement of agood, re-performance of the service, a gift, or other suitablerecompense.

The system identifies the merchant and presents the potentially adversereport and the predicted solution(s) to the merchant, via the merchant'sdevice, for resolution (Step 605). The merchant can choose to take noaction or, on the other hand, can prefer to resolve the issue with thecustomer so that the adverse report does not affect any online scoringor online rating that the merchant can have built up over time. Themerchant's opportunity for responding or not can be limited to apre-determined amount of time (Steps 607 and 609). Hence, if themerchant positively chooses to take no action or if the predeterminedamount of time for responding lapses without the merchant choosing oneor the other, the marketplace server can be adapted to alert thecustomer to the negative or non-response and can, further, determinewhether or not the customer desires to withdraw or otherwise cancel theadverse report (Step 617). After receiving the customer's choice tocancel or not, the Marketplace Server 100 can be adapted to delete theadverse report and prevent publicizing thereof should the customer optto cancel the adverse report (Step 619).

If, on the other hand, the customer has indicated a desire to proceed,the Marketplace Server 100 can then provide the customer with theopportunity to modify the adverse report (Step 621). For example, thecustomer can desire to include in the adverse report that the merchantfailed to negotiate a settlement of the event giving rise to the adversereport. In the event that the customer desires to modify the adversereport, the customer can make additions or deletions to the written,free-style comment area and/or to the pre-designated ratings portion ofthe report. Once the customer has finished making additional or revisedcomments, the modified adverse report is transmitted to the MarketplaceServer 100. Upon receiving the modified adverse report (Step 623), theMarketplace Server 100 posts the modified adverse report to themarketplace (Step 625) via the communication network. Alternatively, ifthe customer does not modify the adverse report, the Marketplace Server100 can, instead, post the original adverse report to the marketplace(Step 625) via the communication network. Either way, once a merchanthas ignored or decided not to negotiate with a customer over a submittedpotentially adverse report, the adverse report can be publicized eitherin its original form or in a modified form (Step 625).

Assuming, instead, that the merchant opts to respond to the potentiallyadverse report, the merchant can do so, for example, using a written,free-style portion as well as a pre-programmed negotiation offer. Afterreceiving the merchant's response, the Marketplace Server 100 canestablish bilateral communication between the customer and the merchant(Step 611) during which the customer and merchant can go back and forthin an effort to resolve the issue that is the source of the adversereport. Advantageously, during bilateral communication, the adversereport remains unpublicized, pending the results of the bilateralcommunications. If the parties to the bilateral communication are ableto resolve the issue that is the source of the adverse report to thesatisfaction of both parties (Step 613), after receiving this decision,the Marketplace Server 100 can delete the adverse report and/or canstore the adverse report in a database of non-publicized adverse reports(Step 615). In either case, the adverse report is never made public.

In contrast, after establishing bilateral communication (Step 611), werethe Marketplace Server 100 to receive a signal indicating that theparties could not resolve the issue that is the source of the adversereport, the Marketplace Server 100 can be adapted to determine whetheror not, in light of the negotiations, the user desires to withdraw orotherwise cancel the adverse report (Step 617). After receiving thecustomer's choice to cancel or not, the Marketplace Server 100 can beadapted to delete the adverse report and prevent publicizing thereof(Step 619) should the customer opt to cancel the adverse report.

If, on the other hand, the customer has indicated a desire to proceed,the Marketplace Server 100 can then provide the customer with theopportunity to modify the adverse report (Step 621). For example, thecustomer can desire to include in the adverse report the tone and temperof the negotiation to the adverse report. In the event that the customerdesires to modify the adverse report, the customer can make additions ordeletions to the written, free-style comment area and/or to thepre-designated ratings portion of the report. Once the customer hasfinished making additional or revised comments, the modified adversereport is transmitted to the Marketplace Server 100. Upon receiving themodified adverse report (Step 623), the Marketplace Server 100 can postthe modified adverse report to the marketplace (Step 625) via thecommunication network. Alternatively, if the customer does not modifythe adverse report, the Marketplace Server 100 can, instead, post theoriginal adverse report to the marketplace (Step 625) via thecommunication network. Either way, once a merchant has ignored ordecided not to negotiate with a customer over a submitted potentiallyadverse report, the adverse report can be publicized either in itsoriginal form or in a modified form (Step 625).

In another implementation, after establishing bilateral communicationsbetween the user and the merchant, the method can include theMarketplace Server 100 executing instructions for receiving and storingas data the negotiation feedback, which can manifest as written,free-style comments by both parties and/or as pre-designated ratings.The Marketplace Server 100 can process negotiation feedback data andassign feedback ratings to the negotiation feedback data.Advantageously, the marketplace server can publicize the assignedfeedback ratings. For example, if the merchant is a merchant thatdelivers services to the customer, enabling the customer to providenegotiation feedback can include generating a plurality of specificquestions about the specific services provided by the merchant andproviding the customer with at least one of a plurality of specificquestions that is unique to services provided by the merchant.

In yet another implementation, the method can further include monitoringa number of adverse reports against each discrete merchant and assigninga rating to each discrete merchant as a function of, inter alia, adversereports that lead to bilateral communication or to publication. Forexample, the rating assigned to each discrete merchant can be based onproposed resolutions received from the merchant via the bilateralcommunication.

Appointment Confirmation Confidence

Using a combination of the described network service technologiescombined with the tracking of each merchant and professional's on-timeperformance, Appointment Confirmation Confidence information can becollected and provided to consumers and merchants who use the system incombination with the marketplace and the network. Merchant on-timeperformance is a measure of appointment schedule adherence of themerchant, and can be based on, for example, whether the merchantreceives customers on or around their scheduled times, the frequencywith which the merchant exceeds estimated service completion times, thelikelihood that the merchant will cancel the appointment, and the like.The information can be maintained in the Consumer Persona 119 forconsumers and/or in the Merchant Profile 117 for merchants.

As one example, a consumer decides whether to change merchants for amonthly in-home pet grooming appointment. The consumer initiallybelieves that the merchant having the highest customer feedback ratingsis also the best service provider. As an additional check, the consumercan review the merchant's on-time performance, during which the consumercan learn that the merchant is on average ten minutes late in startingscheduled services. The consumer can choose the merchant in spite of thehistorical late performance, but the consumer knows what they're buying.Indeed, in this example, the consumer knows in advance that the merchantwith the high feedback ratings is consistently late, and likely will belate, so their expectations are adjusted in advance.

Referring now to FIG. 7, one implementation of a method for makingcertified appointments will be discussed. At Step 701, the MarketplaceServer 100 determines the on-time performance of the merchants on thesystem. When a request for a service is received from a customer device(or the device of a third party) (Step 703), the system selects amerchant that meets a threshold level of timeliness in providing theservice (Step 705). For example, a customer seeking a manicure canindicate, using the User Interface 120 on her device, that she wants topatronize a merchant that begins its appointments on time (whether formanicures or all appointments generally), at least 95% of the time. Inaccordance with the customer's preferences, the system will select atleast one merchant meeting the timeliness threshold, if any (Step 705),and either present the possible choice(s) to the customer along with thehistorical on-time performance data of the merchant(s) (Step 707),and/or attempt to schedule the appointment automatically. In someimplementations, the merchant is selected by predicting that aparticular merchant meets a threshold probability of being selected bythe customer to provide the service. The prediction can be based onhistorical data relating to the attributes of different merchants thathave previously provided the service. As described elsewhere herein, theprediction can be made using a suitable machine learning technique. Themerchant (or merchants) presented to the customer can be those havingthe highest probability (or probabilities) of selection by the customer.

Upon providing the on-time performance data of the merchant(s) to thecustomer (Step 707), the customer can be given an opportunity to opt outof scheduling an appointment with that merchant or merchants (Step 709).If the customer elects to opt out, the system can attempt to findadditional merchants providing the desired service that meet the same ora different on-time performance threshold. In one implementation, if thecustomer chooses not to opt out, and instead selects a particularmerchant with which to schedule the appointment, the customer's on-timeperformance data can be provided to the merchant (Step 711). Forexample, the merchant can be provided with information indicating thatthe customer is late to appointments 8% of the time, has canceled 3appointments with less than required notice, and has failed to show upto an appointment without notice once. Based on the customer's on-timeperformance data, the merchant can then decide whether to opt out ofserving the customer (Step 713). If the merchant chooses to opt out(either manually or automatically based on, e.g., a merchant preferenceattribute requiring customers to meet a threshold on-time performance),the system can select other merchants meeting the same or a differentthreshold of timeliness for presentation to the customer. If, on theother hand, the merchant elects to service the customer, the appointmentis scheduled for the service on the calendars of the merchant andcustomer (Step 715).

Following the scheduling of the service (Step 715), the system canmonitor the calendars of the merchant and/or customer for changes to theappointment (e.g., changes caused by appointment exchanges,cancellation, and the like). In one implementation, the geographicallocation of the customer device is monitored and the customer'sestimated time of arrival to the merchant's location is calculated todetermine if the customer will be late for the appointment. If thecustomer is expected to be late, the a notification of late arrival canbe sent to the customer's device and/or the merchant's device. Themerchant can proactively change the appointment in response to theexpected late arrival, and the Market Server 100 can receive the change,notify the customer device of the change, and receive acceptance of thechange from the customer.

Benchmarking

As earlier described, the Marketplace Server 100 facilitates comparativeanalysis, for both consumer and merchants, of the costs paid byconsumers for services and the services provided by merchants. Forexample, without being provided identifying information aboutcompetitors, merchant can use the present system to determine how aparticular service offering is priced on their price list relative toany particular market. This functionality allows a consumer to comparewhat she paid for a standard service to what others paid in the samemarketplace or what others can pay in other marketplaces. For theconsumer, using the market intelligence available via the MarketplaceServer 100, the cost paid for a particular service can be compared towhat others in the network have paid, without disclosing identifyinginformation associating with the merchants or other customers.

The functionality is also designed to allow a merchant to compare itsservice personnel's performance efficiency with others in itsmarketplace on in other marketplaces. Comparisons can be madegenerically, meaning that other party's identities or detailedinformation are not released. For example, following a tire rotation andoil change service, a consumer wants to compare the rate they paid tothe average paid for the specific service in the marketplace where theservice was delivered. The system's functionality allows the consumer todo this and to also compare what they paid to averages in othermarketplaces. Advantageously, the review helps consumers gauge theirmerchant decisions to save money while, on the other hand, merchants cancompare their productivity statistics with the average in theirmarketplace or the average in other marketplaces.

In other implementations, using the market intelligence availablethrough the Marketplace Server 100 and the Appointment Data 118, aconsumer can benchmark her service purchases against others based onvarious form of demographics or particulars that exist. For example, aconsumer can find that she schedules oil changes for her cars lessfrequently than others, or she visits her dentist for hygiene lessfrequently than others. Knowledge of both habit benchmarks providesearly indicator for potential issues that can cause problems for theconsumer, e.g., car failure or higher dental costs for restoration work.

FIG. 8 depicts one exemplary method for consumer benchmarking inaccordance with an implementation of the system. Initially, theMarketplace Server 100 obtains various attributes for a particularcustomer (e.g., identification attributes, preference attributes, assetattributes, and/or task attributes, as described herein) (Step 801). Thecustomer attributes can be obtained from the Consumer Persona 119 viathe Buyer Matching Engine 102. Further, a desired service is identifiedby the customer or automatically by the system (Step 803). Using itsknowledge on available merchants that provide the service, theMarketplace Server 100 determines which merchants are likely to beselected by the customer. More specifically, the Marketplace Server 100predicts, based on historical data relating to the attributes of themerchants, whether each merchant meets a threshold probability of beingselected by the customer to provide the service (Step 805). Themerchants selected for evaluation can be, for example, those merchantsthat are geographically proximate to the customer, those that haveprovided the service to the customer in the past, and/or those that havepreviously provided the service to other customers having attributessimilar to the particular customer.

As described elsewhere herein, the Marketplace Server 100 can make thepredictions using a suitable machine learning algorithms. For example,the system can train a classifier to predict whether a given merchantwould be selected to provide the desired service using relevanthistorical merchant and customer attribute data, such as the attributesof different merchants that have previously provided the service. Theattributes of the merchant and/or customer at issue are then input tothe classifier to obtain the prediction as output.

For the merchants that are predicted as likely to provide the service tothe customer, the system obtains cost information, including amountspaid by customers who have received the service from the merchant (Step807). This cost information, as well as other information about merchantservices, can be collected over time, as the services are performed orthereafter. For example, the system can collect service information,amounts paid for particular services, service times, and other relevantattributes from customer records, service records, medical records,reports, billing documentation, invoices, and other data available tothe system. The system can remove identifying information from the costand other information (Step 809); for example, prior to providing theinformation to a customer, the system can remove the names, addresses,telephone numbers, email addresses, and so on, of the merchant providingthe services and the consumers receiving the services. Further, ratherthan providing the customer with a list of amounts paid, the MarketplaceServer 100 can combine the cost information into a user-friendly form,such as an average amount paid by customers receiving the service in thecustomer's surrounding area. Once the information is processed into aconvenient form, it is provided to the customer's device for viewingand/or further analysis (Step 811). In some implementations, theinformation can also be provided to one or more of the merchants, eitherautomatically or upon the request of a particular merchant.

Dynamic Pricing

The system can be designed to track consumer demand for appointmenttimes, even when the appointment time has been confirmed and iscertified as controlled by another consumer. Whenever a merchant acceptsan appointment, the additional demand by others for the same time maynot be known or tracked by the merchant. Knowing that informationprovides the merchant with market demand data that allow them to pricetheir appointment times at different levels, e.g., higher prices forhigher demand and lower prices for lower demand. The system tracks allrequested times and allows the merchant to view the demand informationto help them assess prices for their services. This functionality canalso help them assess whether adding additional resources will beeffective in capturing additional revenues.

This functionality of the system can be used exclusively by the merchantto determine the fees that they should charge for their services;sometimes higher and sometimes lower. Advantageously for consumers, ifthey can only schedule appointments in high demand times it will resultin higher costs for them however, if they can work around schedule timeswith lower demand, it can result in lower costs. If higher demand timesare definitely important to a particular consumer, the higher priceswill result in more availability. For merchants, overall revenue fromservice fees can be increased without adding additional costs, unlessthey are expanding their operations to meet the tracked demand, in whichcase, their net profits can be increased.

Barter Exchange

Barter Exchange allows merchants to exchange services without exchangingcash. Using the marketplace ongoing data, the Barter Exchangefunctionality provides merchants with independent valuation of theexchange prices so that all exchanges can be as financially equitable aspossible. Barter Exchange allows merchants to exchange services withoutexchanging cash. Thus, merchants who operate different type of servicebusinesses (such as a barber and a dentist) can exchange value incoupons and use the coupons to reward their customers. For example, if adentist exchanges three 20-minute new patient exams with a barber forsix 45-minute haircuts and stylings (or, perhaps, six coupons with avalue of $50 for that barber), the Barter Exchange initiates thetransaction, values the coupons with market data, allows the coupons tobe electronically transferred and tracks their use. The barber digitallygives them to customers when he learns that they are seeking a newdentist and the dentist digitally gives the hair styling coupons topatients either as a reward or when they learn that the patient isseeking a new hair stylist. The Barter Exchange can also automaticallyoffer the coupons to a patient or customer when they are new to aparticular area and have made an appointment with one of the serviceprofessionals.

Advantageously, for merchants and professionals, they have an easyprocess to assist each other's business. They have a tracking system tovalidate the value of the exchange and to track the exchange for theirincome tax reporting. They provide their patients or customers with costsavings value and give them the service of suggesting merchants orprofessionals that they know are highly desired. The coupons can also beused for the acceptance of new patients or customers via referral whenthe merchant or professional is not otherwise accepting new business.The issuance and use of the coupons is digitally tracked for validationand management. Consumers, on the other hand, receive a referral from aknown person. They save money and their coupon is digitally given andtracked so their use is easy to execute and track.

Marketplace Coupons

Another aspect of the system can provide discount coupons and anautomated tracking system, to reward consumers who use the merchants whoare in the system's network and marketplace. The use of in-networkmerchants is tracked in the Appointment Data 118, through theMarketplace Server 100. To track and properly reward actual service paidand delivered, the system uses activity levels that are based oncertified appointments that have been administered through the system'snetwork and marketplace, including payment. As an incentive to rewardthe use of merchants inside of the system's marketplace, this aspect ofthe system allows the marketplace to reward consumers with discountcertificates or coupons for services and products when levels arereached. For example, if a particular consumer has used ten newin-network merchants during a particular period of time, e.g., during asix-month period of time, they could be rewarded with a certificate fora $100 service from another merchant in the network and the marketplace.

Advantageously, buyers/consumers receive discount certificates that canbe used to purchase other in-network services. While, the network thatthey join by using the system marketplace provides incentives for theseller's customers, and customer prospects, to use the merchants in thenetwork. Different coupon and reward programs can be used for differenttypes of services, such as rewarding someone for returning to the samemerchant for the same service over a particular period of time.

Coupon Redemptions

The “Redemption Gap” is currently a significant issue for eCommercecompanies who are engaged in the “daily deal” business. This gap is thedifference between all coupons issued and coupons redeemed. For revenuepurposes and to prevent the loss of the benefits of coupons before theyexpire, the system can be adapted to electronically record all couponspurchased by or issued to consumers. In addition, it can allow consumersto enter coupons purchased in out of network sites like GroupOn orLivingSocial so they can be recorded (although, as an out-of-networkpurchase, it cannot automatically track redemptions). In all cases,coupons are either automatically entered or scanned into the systemthrough the Consumer Persona 119 so that the Buyer Matching Engine 102can automatically apply the consumer's preferences for the redemption ofthe coupons and remind the consumer when expiration is approaching. Forexample, if a consumer is issued a coupon for frequenting an in-networkmerchant, it is issued through the Appointment Data 118 and theMarketplace Server 100 and entered into the Consumer Persona 119 and theMemory 105. The system monitors the coupon for expiration date, use fora service that a consumer has requested, transfer to a friend forgifting purposes or to encourage in-network business growth and forultimate redemption. In addition, if a consumer purchases a couponthrough GroupOn, Angie's List, Living Social or one of the other leading“daily deal” eCommerce sites, the coupon can be scanned into theconsumers data and tracked.

Advantageously, for consumers, all coupons are tracked and theredemption gap is eliminated, even if someone gifts a coupon to another,through the system's notification system, so that they can redeem itbefore the expiration date. For the merchant or professional, couponsare issued to grow their business and incentivize their customers toreturn. With this network service, the merchants who issue coupons havecomplete assurance that the coupons will be used for their intendedpurpose.

Coupon Exchange

Coupon Exchange is a marketplace where individual consumers who havepurchased coupons can sell or trade them for value. Also, consumers whouse particular merchants or professionals can enter alerts thatelectronically track when coupon opportunities for those merchants areoffered for sale so that they can take advantage of the opportunity. Forexample, if an individual has purchased a LivingSocial or GroupOncoupon, or another form of coupon that can be transferred, they canoffer it for sale or for trade. This network service can be described asan “eBay for coupons.” Thus, if a consumer owns a coupon for a nailservice that was purchased outside of the network, and he knows that hewill not be able to use it for value before the expiration date, he canenter the information in Coupon Exchange and accept bids to sell it.Thus, for the seller, rather than losing complete value by allowing acoupon to expire without use, the coupon owner, as “seller” can receivevalue in the same manner that a stock investor sells stock “puts” and“calls”. In short, the price for the coupon becomes an “arms-length”negotiation that is set in a free market that factors in the time untilexpiration and the overall value of the coupon. When agreements arereached, the transaction is electronically executed and the transfer isrecorded. Buyers, in turn, obtain access to a marketplace that has notpreviously existed. Moreover, they can receive additional value for acoupon by purchasing it at a discounted price from what the originalowner paid if they are willing to remain flexible on their calendar.Finally, the merchant or professional's coupons are expensive to issueand the use of them helps the merchant achieve the result of, forexample, obtaining a new customer. If the coupon is allowed to expire,the issuing merchant fails to achieve his objective.

Coupon Issuer and Presenter

The Coupon Presenter functionality is a mobile computing device thatelectronically maintains all coupons owned by a consumer, includingthose transferred through Coupon Exchange and Barter Exchange. Theapplication allows users to electronically present the coupon throughtheir mobile computing device for scanning by the merchant orprofessional's scanner. When scanned, the usage is verified and theconsumer's coupon inventory is updated. Also, coupons are “aged” in theconsumer's coupon inventory so consumers can be advised of approachingexpiration dates. The application has a merchant or service professionalfacing application that provides them with tracking of unused coupons sothat the system can send reminders or know how to manage largequantities of approaching expirations.

Coupon Issuer is an application that allows merchants to offer couponselectronically through the system's Internet network infrastructure orthrough interface devices in the merchant's facility or at a retailkiosk. They are used in conjunction with an individual consumers'physical presence at the site. The Coupon Issuer uses Wi-Fi or Bluetoothtechnology to digitally transfer the coupon to the consumer. Forexample, any time an individual consumer purchases or receives a coupon,he enters it into his system and it is recorded in their ConsumerPersona 119. Whenever the consumer uses the services of a particularmerchant for whom she owns a coupon, the coupon is automaticallyaccessed when the consumer makes the appointment and it is automaticallyused as part of the payment process when the consumer uses the system'spayment methods.

Beneficially, for the coupon issuer, coupons are tracked and their usefor the intended result is managed. Furthermore, coupon usage iselectronically managed without the issuance of paper documents andcoupon usage is verified and the individual presenting the coupon iselectronically verified as the owner using the other capabilities of thesystem. Advantageously for coupon owners, their coupons are presented tothem electronically and managed by the system's automated capabilities.Coupon expiration is better managed because the existence of the couponis automatically used when service appointments are made and during thepayment process. For merchant or professionals, the coupons areexpensive to issue and the use of them helps the merchant achieve theresult of, for example, obtaining a new customer. If the coupon isallowed to expire, the issuing merchant fails to achieve theirobjective.

Rewards Program (Consumer Focused)

The system can be adapted to issue electronic reward certificates whenpurchased by in-network merchants for their subsequent gifting to theircustomers. The reward certificates can be for an unlimited number ofthings, including products, food items, and other services. The rewardprograms administers all certificates electronically, such that whenevera merchant gives one to a customer, they do so by scanning thecustomer's unique barcode identity into the mobile device that they useto manage their business, e.g., via an iPhone, an iPad or a barcodescanner connected to a computer, and by selecting the reward that theyare giving. The Marketplace Server 100 executes the transaction. Hence,when the customer uses the reward, he only has to show the coupon on hismobile device to the redeeming merchant. There is no paper issuance ofcoupons at all. For example, a haircut salon is interested in helping acoffee shop that is located next door. With this feature, the salon canpurchase electronic gift certificates for cups of coffee and, when theyfeel it is appropriate, they give them to their customers. Customersreceive a reward for whatever reason that the merchant believes isappropriate. Merchants or professionals build goodwill with theircustomers.

Reward Administration (Merchant Focused)

The system, through the Marketplace Server 100, the Consumer Persona119, and the Merchant Profile 117, can also be structured toelectronically record and track the status of all reward and couponissuances so that the merchant can measure how they are used anddetermine the effectiveness of each type of reward or coupon program.For example, a particular merchant can offer electronic coupons throughthe marketplace that is operated by the system. They can also giveelectronic reward certificates to their customers for use to purchaselunches at a restaurant that is located down the road from the merchant.The system provides on-line reporting that shows how each coupon orreward in each program was used and how effective they were. Thus, atany moment, a merchant can see how many coupons were purchased in themarketplace, how many of them were purchased by existing customers (andwho they were), and how many of them were purchased by new customers.Advantageously, merchants or professionals can see how many coupons havebeen used and how many are coming to expiration. They can also set theirMerchant Profile 117 preferences to remind coupon purchasers ofexpiration dates.

For consumers, use of rewards and coupons is tracked so that they do notlose them while for merchants or professionals, the completeeffectiveness of every reward and coupon program is tracked and analyzedand the merchant benefits are calculated to be provided to the merchant.

Complementary Service Engine

The Complementary Service Engine uses the preferences in an individualconsumer's Consumer Persona 119, in conjunction with the Buyer MatchingEngine 102, to present opportunities for the purchase or use of servicesthat a particular consumer has shown a history or preference to usetogether. For example, a consumer can have a recurring haircutappointment every fourth Saturday with a particular barber at aparticular barber shop and can infrequently schedule an oil change forhis car and a massage in the same vicinity. Advantageously, theComplementary Service Engine can be adapted to note the pattern andsuggest to the consumer that a massage be scheduled after every haircutand, further, to coordinate the mileage reports from the consumer'sOnStar system to schedule an oil change, concurrent with the haircutappointment, at a particular oil change retail shop located a block awayfrom the barber shop. If approved by the consumer or, alternatively, setup as a preference in their Consumer Persona 119, the systemautomatically schedules the appointments. For the consumer, the systemproactively monitors and automatically manages patterns of serviceappointments in the user's life. Merchants and professionals, on theother hand, receive an automated recurring scheduling service.

Location-Based Opportunity

Location-Based Opportunity is a software engine that can be adapted towork via the Consumer Persona 119 and the Buyer Matching Engine 102 tomatch objectives with tasks that can be completed when a consumer'sgeographical location is proximate to where the objective can beaccomplished. For example, a consumer's spouse can have a task list thatincludes various errand items. The consumer can also be linked to thetask list. As the consumer is driving home from work, she can be alertedthat a task list from that link includes “pick-up dry cleaning from AcmeCleaners on Main Street.” The consumer can be queried as to whether ornot she would like to accomplish that task and, advantageously, can beadvised that accomplishing the task would not affect a next appointment.If the consumer decides to accept the task, the system can provide herwith directions to the location of the dry cleaner. Furthermore, oncethe task is completed, the spouse can be notified and his task list canbe updated. Advantageously, for the consumers, their collective livescan be enriched by the action of others, e.g., a spouse. However, thelinked task list can include neighbors, friends, work colleagues, and soforth. Merchant's objectives are accomplished as this particular examplehelps them complete the delivery of a service that they have rendered.As a result, they are compensated earlier than might have otherwiseoccurred.

iForms Exchange

The system can also be configured to collect and prepare an archive ofstandard industry forms templates in the Marketplace Server 100 throughthe work and management of the system's operator. The standard forms arein an electronic library and contain data fields that can be populatedat any time using the information in either the Merchant Profile 117 orthe Consumer Persona 119. Thus, when a consumer has scheduled,certified, and confirmed appointment was a merchant or professional, theMarketplace Server 100 works with the Merchant Profile 117 to determineexactly what forms are required and then connects with the ConsumerPersona 119 to retrieve data to populate the fields in all requiredforms (subject only to the consumer's settings in their persona) and toelectronically issue the completed forms to the merchant orprofessional. Upon issuance, all forms are distributed within themerchant or professional's preferences however, the information cannotbe distributed or issued outside of the merchant or professionalsoperations unless authorized the consumer. For example, if a consumerhas scheduled an appointment with his doctor for an annual examination,he can be required to update various forms, which can include medicalinsurance forms, prescriptions, current medical conditions, anyinjuries, and the like. The system can be configured to prompt theconsumer for permission to prepare the forms (unless the consumer hasgiven pre-approval in their Consumer Persona 119 preferences) and toelectronically populate the forms with the information that is requiredby the medical professional.

If the medical professional's required forms have changed and additionalinformation is required, the consumer is notified and prompted to obtainthe information. When the needed information is obtained, the consumercan enter it into his Consumer Persona 119, where it is stored for otherreleases needed by other merchants or medical professionals. Note,however, that since the medical professional uses the system's standardforms library, when updates to a standard form are made, all consumersare notified that it is needed. When the information is obtainable froma third-party source on behalf of the consumer, the system can beadapted to obtain the consumer's approval, to contact the third partyand to electronically enter the information in the Consumer Persona 119(and to notify the consumer for their review). When the consumer arrivesat the doctor's office for their certified confirmed time, they areimmediately taken to the examination room and not asked to completemanual forms or to wait.

Advantageously, one of the noisome processes involved in purchasingconsumer services, i.e., forms completion, is completed for the consumerautomatically and with minimal intervention. At the merchant's end,forms and data that they need are defined and, as a result, arecompleted before the services are provided. Furthermore, the merchantsor professionals receive the needed information in advance.Consequently, if the appointment relates, for example, to a medicalexam, the insurance information is taken care of electronically and themedical professional is assured of payment even before the examinationor other service is performed.

Automatic Reminder and Alerts

The Marketplace Server 100 can also be adapted to use the MerchantProfile 117 preferences regarding necessary procedures before a servicecan be delivered to notify the consumer through the Buyer MatchingEngine 102, to ensure that necessary protocol procedures are followed.Also, the Marketplace Server 100 can use various information in theMerchant Profile 117 and the Consumer Persona 119 to automatically alertrequired actions, e.g., as a reminder message. For example, if a patientis scheduled for surgery on a particular day, the Automatic Reminder andAlert function can be adapted to provide the patient with automaticnotifications of conditions such as the requirement that they not eatfrom 6:00 p.m. on the night before surgery. The Automatic Reminder andAlert function can also interface with the patient's calendar todetermine if any events are scheduled that might cause non-compliance,e.g., a dinner meeting that is scheduled for 7:00 p.m. The AutomaticReminder and Alert function can also connect the merchant orprofessional's calendar with the consumer or patient's calendar, e.g.,to provide reminder notifications that ensure that the appointment timewill be followed and that issues that can cause appointments to bemissed or delayed are identified. For the consumer/patient, necessaryprotocols are automatically notified in the preference format that thepatient or consumer prefers to help them maintain their performanceratings high and to keep their calendars on focus. At themerchant/professional end, necessary and required reminders are providedautomatically, which provides assurance that safety protocols arefollowed. Moreover, the Automatic Reminder and Alert function helps themerchant or professional maintain business results by ensuring thatcustomers and patients arrive for their appointments.

Marketplace Payment

The Marketplace Server 100, in conjunction with the Consumer Persona 119and the Merchant Profile 117, can also be designed to collaborate onpayment processing that is directed as a payment from the consumer tothe merchant. The Marketplace Server 100 executes the clearing of thepayment. The payment transaction is initiated either at the time of theservice, or earlier, in the case of a prepayment or deposit. Whenpayments are made at the time of service, the system uses the barcodeidentity and location-based scanning to verify that the consumer is theperson who reserved the appointment and is the one making the payment.It can also verify that the consumer is actually at the site. Thisfunctionality, for example, can be used for a consumer's payment,whether it is for a prepayment or a payment at the time of servicedelivery.

For example, if a consumer schedules a massage appointment three weeksin advance, the merchant can offer a prepayment discount if the consumerpays in advance. Or, as another example, the consumer can choose to payfor the service after the service has been delivered. In the lattercase, the consumer scans their unique barcode into the merchant'sscanner to identify herself. The consumer can be queried, e.g., via amobile device, if she wants to pay for the service, which can includeinclusion of a gratuity. If the answer is “yes” regarding the gratuity,the consumer is prompted to see if she would like to see guidelines forgratuities for the type of service they have received, e.g., using thesystem's standard service type codes. If she answers “yes,” she can beshown guidelines and prompted for the amount she would like to include.When satisfied, the consumer enters “ok to pay” and the merchant'spayment request is received by the Marketplace Server 100 fordistribution to the merchant. Consumers experience safe payment througha known system and guidelines for gratuities so that their reputation ismaintained and they are not paying too much for what they receive.Merchants or professionals receive faster payment, which can includepre-payment for discounts if desired, and a safe system that matches allcertified confirmed appointments where delivery has occurred with thereceipt of payment. The function can also provide security from employeetheft in instances in which merchants operate remote operations andprotect the merchants from losses from unknowingly accepting checks withnon-sufficient funding in the account.

Task Acquisition

The system can further include a task list functionality in the ConsumerPersona 119 for consumers to enter their desired tasks relating toconsumer services. At the time of the entry, the consumer is promptedfor classifying details so that the task can be property addressed. Ifthe task relates to consumer services where the consumer has set-upsourcing preferences in his Consumer Persona 119, he may not be promptedand the system initiates the action of addressing their service requestautomatically. For example, a particular consumer can be at his officeand realize that he needs a haircut but has not scheduled it prior to anupcoming business trip. He reaches for his iPhone and presses the buttonto engage Apple's “Siri”. He advises Siri to make a haircut appointmentthrough the system prior to the date of his upcoming business trip. Siriacknowledges and immediately accesses the system's User Interface andenters the task in the consumer's task list. Upon entry, the system,e.g., via the Buyer Matching Engine 102, can access the Consumer Persona119 to determine that this consumer uses the same barber for all of hishaircuts. The Matching Engine 102 can then be configured to contact theMarketplace Server 100 to schedule the haircut appointment. Using theAppointment Data 118, the Marketplace Server 100 can negotiate betweenthe barber's calendar and the consumer's calendar to find a time.Furthermore, the system can identify that the consumer has a boardmeeting within two blocks of the barbershop in the week before hisbusiness trip. Based on the travel time algorithms and the board meetingstart time, the haircut can be scheduled automatically an hour beforethe board meeting and the appointment is confirmed and certified andentered on both the barber's and the consumer's calendar.

Advantageously, the appointment was scheduled in the timeframe neededand within an efficient time on the consumer's calendar with limitedinvolvement from the consumer. At the merchant end, the appointment wasscheduled on the barber's calendar with an existing customer without anyinvolvement from the barber.

Work Task Tracking

The system can also be adapted to use the Buyer Matching Engine 102 toprepare lists associated with a service that is scheduled. The lists arebased on the relevant information in the Consumer Persona 119, e.g.,identifying the type of car, the current mileage, and so forth, as wellas service notations that are transmitted by third-party systems, e.g.,OnStar, relating to issues noted in a car. The lists can be transmittedthrough the Marketplace Server 100 to the Seller Matching Engine 101 andlisted in the Appointment Data 118 for the upcoming certified andconfirmed appointment. When the service is initiated, the system caneither populate the list on the merchant's work-in-process system or canelectronically transmit a work list, e.g., using a PDF document. Whenthe work is completed, the same list is transmitted to the consumer forher review of what has been completed. For example, a customer, inpreparing for a car service appointment a week out, can access the WorkTask list periodically as she notes the work that needs to be done onher car. The information is updated on all appropriate files so that itcan be transmitted. When the consumer picks up the car, she can reviewthe list with the merchant and in connection with her review of the bill(pre-payment) to ensure that everything was addressed. For the consumer,the system provides an organized manner in which to prepare a work listand in which to review completion and billing. Merchants orprofessionals can be advised in advance of what is required and can takeaction to ensure that any needed parts are available to minimize theamount of time that the car spends in their repair shop. Also, themerchants can eliminate the time to re-enter work information while thecustomer is in their shop, providing more resources to address the work.

Capacity Sale (Merchant Focused)

The system can also be adapted to enable merchants to access theAppointment Data 118 to determine their upcoming, confirmed appointmentschedule. When openings are noted or blocks of available unscheduledtime appear on the schedule, the system can enable that merchant tooffer discounts to existing customers, new customers, returningcustomers or collaborative customers of related merchants. The discountoptions can be based on customers committing to the slot and(optionally) paying in advance for the appointment, or making a deposit.Advantageously, consumers can set their preferences in their ConsumerPersona 119 to seek such deals using the work that exists on their tasklist. For example, a particular merchant may note that four weeks out,90% of their service resources are not scheduled. Rather than wait tosee what work can come up, the merchant can decide to offer a sale toexisting customers for 40% of his available time (taking his schedule upto 50% three weeks out). He can also opt out of the prepayment optionsince he is offering the capacity sale to existing customers. As aresult, the consumer receives the discount for committing to take anopen time slot for work that they either currently need or that theyneed in the future, while the merchant is able to project his open timeslots and to fill them with schedule worked.

Active Marketing

The market intelligence that is contained in the Appointment Data 118,and the generic information that can be “mined” in the Merchant Profile117 and the Consumer Persona 119 can be provided to merchants to helpthem prepare for opportunities to address customer needs in theirmarkets or in the markets that they are exploring. For example, aServiceMaster franchise owner can be considering expanding operations toa city that is 50 miles from their current location because they havehad multiple requests for work in that area but have believed that it istoo far to travel in a business day. Although they have had requestsshowing interest and possible demand, the merchant can first explore themarket as completely as possible. Using the system, they can access theproposed area's market information to seek: the average age of thehomeowners in the area; the number of homes in which the owners haveowned them for five years or more; and the volume of home maintenanceand repair business that has transacted through the system'smarketplace. Such information will help them understand the potential ofsuccess should they decide to move forward with their plan.

Consumers in the area can benefit from a ServiceMaster franchise that islocal. Moreover, if this is in addition to other similar franchises inthe area, they benefit from the competition for their business. If thisis the first of this type of business in this area they benefit from thelower costs for the franchisee to travel to them. Merchants orprofessionals can be able to grow their business with reliable marketinformation and can have a higher probability of success.

Opportunity Capture (Sale)

Using a combination of the task acquisition functionality and theConsumer Persona 119, operating in conjunction with the Buyer MatchingEngine 102 and the Marketplace Server 100, the system can allow aconsumer to continuously search for service opportunities usingselection criteria relevant to what the consumer is seeking. Forexample, a consumer typically brags to his friends that he pays no morethan $20 for oil changes in a market where the average price is $40.Using an opportunity capture search that works through the BuyerMatching Engine 102 to continuously review market transactions and saleopportunities that match that price, the consumer can continue to pay nomore than $20. Although they do not come up frequently (as they aretypically “loss leaders” for service garages), every few months or sothey do appear and this customer is notified. When he receives thesenotifications, he confirms an appointment. For opportunity capture(sale), the acceptance of an offer may not be automated since a numberof options can be presented. With such a functionality, the consumer'spricing needs can be met while merchants or professionals can berewarded with additional revenue and expand their business.

Service Bid

Using a combination of the task acquisition functionality and theConsumer Persona 119, operating in conjunction with the Buyer MatchingEngine 102 and the Marketplace Server 100, the system can allow either aconsumer or a merchant to select criteria which, if met, would result inthe confirmation of a service appointment. For example, a consumerseeking a carpet cleaning service for their 1,500 square foot,fully-carpeted home can have searched the market and concluded that$0.50/square foot for the carpet is a fair price. However, the consumercan still enter the search criteria at $0.40/square foot under thecondition that the merchant can give them as short as an hour advancenotice for them to be ready, i.e., complete merchant flexibility. Thefollowing morning, a newly-established merchant may notice theopportunity and contact the consumer, offering 24-hour notice at$0.40/square foot. With this result, the consumer's pricing needs weremet and they had the service scheduled (with even more advance noticetime than they agreed to accept). The merchant or professional closed asale and gained a new customer.

Ad Tag Sourcing

Typical consumers do not like to receive advertising spam. Accordingly,the system can be configured to completely blocks out spam through themarketplace, e.g., via the Marketplace Server 100, and the Seller andBuyer Matching Engines 101 and 102. However, there are times when aconsumer can be interested in a particular advertisement, such as whenthey are searching for a particular service, e.g., one on the consumer'stask list. In such an instance, consumers can be enabled to enter a keyword(s) that they believe would be in an advertisement for somethingthey are seeking. The more words added to the ad tag, such as an ad tagphrase, the more selective that the reverse search will be. Thus, whenthe system's Marketplace Server 100 receives an advertisement thatmeet's the consumer's ad tag or ad tag phrase, the consumer is alertedto the advertisement and provided the option to receive it. If theconsumer chooses to receive the advertisement, the ad revenue that ispaid by the search engine to the system's operator is shared equallybetween the operator and the consumer. The system can include a “reversead tag” library where all reverse ad tags that are selected by consumersare collected and stored.

For example, a particular consumer can seek a cell phone repair for aparticular model cell phone. The consumer can use the ad tags“Motorola”, “Cell Phone”, “Motorola Repair”, and “Quick Motorola CellPhone Repair” and input it into her Consumer Persona 119. Within a 24hour period of time, she can receive, e.g., a text message notificationfrom the system, advising that two ads met her criteria. The consumercan accept one of the ads. Advantageously, the consumer found a sourcefor her cell phone repair without being inundated with spam advertisingthat he would have had to sift through. The merchant, on the other hand,reached the most focused target for advertising that is possible andengaged a new customer.

Track and Locate

The Track and Locate functionality is configured to include specificcontrols for location and time data as control features in the system.The functionality is accessible with mobile devices through the mobilenetwork and which uses information on the geographical position of themobile device. This functionality is used, with the preference settingapproval of the consumer in the Consumer Persona 119, to advisemerchants of the whereabouts of the consumer so the merchant can beaware of the expected arrival time. Also, the tracking of the on-timestatus of a merchant and the reporting to the consumer who has anupcoming appointment. For example, a consumer has a 9:00 a.m.appointment at an auto repair merchant to have their car exhaustchecked. The process can take the merchant about 15 minutes to complete.The merchant's 9:15 a.m. appointment is early and arrives at 8:50 a.m.The merchant can uses the system's Track and Locate functionality anddetermine that the 9:00 a.m. consumer will not arrive until 9:05 a.m. Asa result, to maintain the merchant's work flow on time, they take the9:15 a.m. appointment into the service bay for the exhaust check. Theycomplete it by 9:05 a.m., when the 9:00 a.m. appointment arrives.

In another example, the same technology is used in a doctor's office.Whenever a patient is taken into the examination room, their mobiledevice notifies the system and the doctor's on-time status is monitored.If the doctor begins to run behind schedule due to unforeseencircumstances, subsequent patients are notified and they are able tomodify their schedule accordingly. Advantageously, for consumers, theydo not have to call the merchant if they are late and, if they areearly, they can be able to complete their service early due to the latearrival of other consumers. Merchants or professionals, on the otherhand, are constantly being advised of status or consumers and their workflow can be maintained according to schedule, which does not impact thesubsequent customers.

Service Delivery Verification

Using the Service Delivery functionality, the system is able to verifythat a service has been delivered before payment is made. When required,the consumer authorizes the system to report the information to a thirdparty using a Consumer Persona 119 preference setting. Preferably,reports are electronically transmitted to the third party as frequentlyas the third party desires. For example, a consumer has recently hadknee surgery and is engaged in physical therapy that is paid by hishealthcare insurance. He has been authorized to receive twelve sessions.At the completion of every session, his insurance company receivesverification that he was at the therapist's office at the time of thesession. When the insurance company receives billings from the physicaltherapist, the company can use these independent verifications toauthorize payment. The consumers know that the services that are beingpaid for are actually received while the consumer can be paid earlier bythe insurance company because they have verification that the servicewas delivered.

Technology Interface

There are many technologies that have been developed that are naturalextensions to the system's products. The system includes interfacetemplates to allow for quick integration in the Internet cloud socustomers can align more information. For example, a particular productcalled CarCare tracks car maintenance activities such as gas refills. Aspart of the tracking, the consumer can enter the car's mileage. Thesystem's interface can accept these data from the CarCare application inthe Internet cloud and can use it to evaluate whether and whenmaintenance actions are warranted. Advantageously, existing technologiesthat are employed are easily integrated into the system's monitoringactivities. For merchants and professionals, needed maintenance isaddressed sooner due to the awareness of the needs.

Identity Verification

The system can also be adapted to include functionality whereby, when aconsumer enters a merchant's facility, the consumer opens the systemUser Interface 120 on their mobile device scans their unique barcodelabel into the merchant's scanner. By doing this, the merchant is awareof the consumer's arrival and the arrival has been matched with thecertified and confirmed appointment. The merchant is also assured thatthe consumer who has arrived is the actual consumer who scheduled andpaid for the service.

For example, a consumer arrives for a first appointment with a newdoctor. The patient scans her unique barcode identity, signaling thedoctor that the patient has arrived. Using the barcode, the doctor canaccess the User Interface 120 to see a photograph of the patient and anadditional level of verification. This protects the identity of theconsumer and ensures that the scheduled services can only be used bythem. This also provides protection from unauthorized payments. On themerchant or professional end, the system can verify third-party paymentsand can also help the merchant eliminate the need for a receptionist orcheck-in person.

Consumer Rating or “Best Customer” Classification

The Marketplace Server 100 can also be configured to track and maintainrecords of the performance of consumers for such things as no-show, ontime arrival, rescheduling frequency, merchant loyalty, and the like;and to provide the records to merchants for the purpose of evaluatingtheir risks in accepting an appointment from a new consumer. A ConsumerRating Classification can be used generically for merchants to comparethe ratings of their recurring consumers to their competitors withoutthe system revealing the customer or competitor identities. For example,a merchant is currently experiencing a customer 15% no-show rate. Themerchant can request information on how that no-show rate compares tocompetitors who operate within a 20-mile radius. Preferably, the systemprovides this information without revealing any identities. Themerchants can review the data, noting that competitors only experience a10% no-show rate. As a result, the merchant can change its businessstandards in their Merchant Profile 117 to only accept new customerswith no-show ratings of less than 2%. Accordingly, from this pointforward, automatically-accepted customers must have that rating orbetter while the merchant will be asked to approve new customers withworse ratings. For consumers, those with better ratings will bepreferred by new merchant opportunities. At the merchant's end, themerchant or professional will be able to address business performance ascompared to their competitors with very specific actions that they canunderstand and that will be automated and become part of their normaloperating procedures.

Merchant Rating or “5-Star” Classification

The Marketplace Server 100 also can be configured to track and maintainthe performance of merchants and professionals for such things as ontime performance, customer feedback ratings, particular adverse phrasesin their feedback, consumer loyalty, and so forth; and to provide thesedata to consumers for purposes of evaluating whether a consumer wouldwant to use that particular merchant. For example, a consumer evaluatingnew dry cleaning merchants can request and review the merchant ratings.Although the consumer finds a 4-star rated merchant within a mile of hishome, he notes that a 5-star merchant is located 5 miles from his home.Examining the details of the performance rating, the consumer can alsolearn that the 5-star merchant's customer loyalty is rated higher. Basedon this data, the consumer can decide that, based on the fact that the5-star merchant retains its customers, it is worthwhile to make theadditional drive. For consumers, this is beneficial because they canengage the merchants and professionals that they know to be higher ratedfrom multiples of feedback from the system's marketplace. Merchants orprofessionals, especially those with higher feedback ratings, will be inhigher demand. Those with lower ratings can evaluate the details oftheir feedback ratings to know how to address the issues that arecausing their depressed ratings.

Universal Data Archive

The system can further be structured to automatically back-up data andto maintain the back-ups in multiple sites so that recovery can beachieved nearly instantaneously if needed. For example, some smallbusiness have never spent the time or valuable funds to set-up a databack-up system for their customer files and their history. This can be acostly issue in the event of data loss. Using the system, suchinformation is automatically protected and the small business owner isprovided a level of back-up and recovery that she could not haveafforded independently. Both the consumer and the merchant benefit fromthe information being protected.

Relationship Management

The system can also be configured to assemble all of the relevantinformation, e.g., feedback, on-time tracking, customer retention, newcustomer coupon use, and various other criteria (as well as criteriadefined by the merchant), to and provide electronic status report of howa merchant or professional's services are being viewed by theircustomers and how the information compares to the marketplace. Forexample, a doctor is considering adding another physician to herpractice but is unsure of how it can affect the current practice. Shecan select the relationship management functionality of the system andreview various factors, noting that for every appointment time that thenew physician has, there are multiple requests for the time. Consumersbenefit because projected needs are monitored and actions are taken toaddress them. Merchants or professionals are able to satisfy theircustomers and patients using relevant information that they would nothave otherwise had.

Recurring Appointment Scheduling

The Marketplace Server 100 can also be structured and arranged with afunctionality to administer various types of recurring appointments onbehalf of consumers. The appointments can be made based on a particularday of a month, e.g., on the first day of every month, or on aparticular day in a particular week, e.g., the second Monday of themonth. The recurring appointment is administered as a certified andconfirmed appointment on the calendars of both the consumer and themerchant. For example, a consumer wants a haircut every three weeks onMonday mornings. They have been frequenting the same barber for morethan ten years and have no plans to change. Using the recurringappointment scheduling functionality, the consumer can request arecurring appointment every third Monday morning at 8:00 a.m. If thetime is available it is booked for whatever period in advance that theconsumer wants and that the barber is willing to commit to.Advantageously, for the consumer, their personal care needs are met andthey do not have to spend time with their barber coordinating futuremeeting times. The merchant or professional satisfies a current customerand has reliable future service commitments

Market Feedback Analysis (Merchant Focused)

The system can also be designed whereby feedback that is submitted to amerchant is constantly compared to the average of feedback that isreceived by similar merchants in the marketplaces that they serve.Trends can be noted and flagged for the merchant. Also, the feedbackpractices of those submitting feedback can be analyzed to determine if aparticular feedback is an anomaly or in line with what the consumer'spractice typically is. Also, at the option of the merchant, feedbackthat meets certain criteria, such as strongly negative, can be flaggedto their attention for immediate follow-up. With this functionality, amerchant or professional is able to see how their feedback relates tothe feedback that other merchants in their marketplace receive. Forexample, a merchant with multiple locations can employ a number ofmanagement techniques to ensure that all locations strive to satisfycustomers. Unfortunately, the owner cannot be at all locations and hopethat their managers are doing all that they can. However, using thesystem's market feedback analysis functionality, the merchant canmonitor at any time how the feedback at their remote locations comparesto the marketplace. If adverse trends are noted, immediate action can betaken. A the consumer's end, the merchant can access tools andfunctionality to ensure that the locations that serve the consumers areperforming up to market standards. At the merchant's end, performanceissues can be addressed immediately and negative customers can beaddressed.

Coding Structure—Attribute Codes

In one implementation, the system includes a standard coding methodologyto manage, organize and catalogue consumer and merchant attributes.Identified herein as “Attribute Codes,” they are structured to operateat three primary levels to enable all marketplace constituents (i.e.,consumers and merchants) to manage and control their identification andpreferences and to allow the Buyer Matching Engine 102, the SellerMatching Engine 101, and the Marketplace Server 100 to optimally matchtheir needs, preferences and task goals.

For example, a consumer can own an automobile that requires maintenanceand repair. By identifying this as an “automobile,” the matching engineis not able to specifically prescribe solutions to satisfy theconsumer's needs. However, by identifying the “automobile” as, forexample, a 2008 Ford Taurus with 40,000 miles, the vehicleidentification number and the location, the system's Matching Engines101, 102 and Market Place Server 100 are able to assign one or morestandard Attribute Codes to this vehicle, which facilitates the specificmatching of the needs of the consumer with the capabilities of themerchants.

Standard coding through the system's Attribute Coding process alsoallows for the collection of a library or index of Attribute Codesequences that are combined to satisfy a particular task or need. Forexample, in the above hypothetical situation with the 2008 Ford Taurus,there are number of decisions and choices that are required to optimizethe match between the asset needing repair and the merchant best suitedto address the need. For example, various information and attributes caninclude the vehicle identification number, the mileage, the identifiedproblems, owner coupons, past service records, whether the merchant canfix the identified problems, equipment required to fix the vehicle, andso on. Each of these information items has a identifying Attribute Codeto conform it to the population of similar information. By matching thisinformation to a uniform Attribute Code, the consumer's needs arespecifically matched and the merchant's capabilities are specificallyaligned with the needed remedial actions and the expertise of theresources.

Attribute Code Matching

In a simple example of Attribute Code matching, and referring back tothe 2008 Ford Taurus, the car identity noted by the vehicleidentification number is matched with the unique code for this model ofautomobile and sub-codes are derived for the year of the vehicle, themanufacturer, the date of manufacture (and therefore the age), thewarranty records, the source of previous service records and so on. Eachof these items can be a separate Attribute Code but, by the particularsprovided, these separate Attribute Codes are joined to provide aAttribute Code for the vehicle. This action can be completed by theMarketplace Engine 100 and, once assigned, is catalogued for this asset.

To continue, using the vehicle's Attribute Code, the manufacturer'srecall and service notification records are sourced and work list items,which have been assigned separate Attribute Codes, are automaticallygenerated for the upcoming service. In addition, the entry ofinformation about the issues with the car are matched with similarissues and resolutions for this particular make and model of car andrecommended work list Attribute Codes are listed to show the serviceprovider what is the likely work process needed. By assigning these workAttribute Codes, the merchant is provided with an average time thatother merchants have required to repair this particular problem and themerchant's facilities are assigned based on these average(experienced-based) Attribute Code work tasks. This example shows only afew Attribute Code matches; however, the matching possibilities arevirtually endless for both consumers and merchants.

Attribute Code Structure

In one implementation, at the top level, Attribute Codes are organizedaccording to consumer and merchant. As such, at the top level of thecode structure are “Consumer Persona Codes” and “Merchant ProfileCodes,” together referred to as “Entity Codes.” Below the Entity Codes,each entity (consumer and merchant) strive to complete tasks andobjectives and each have three “Purpose Codes”: (1) Identification; (2)Preferences; and (3) Tasks. Within the Purpose Codes, both the consumerand merchant have “Objective Codes.” For consumers, this includes: (1)Consumer Fixed; (2) Consumer Variable; and (3) Asset Variable. Formerchants, this includes: (1) Merchant Fixed; (2) Merchant Variable; and(3) Resource Variable.

Consumers generally manage two things: themselves, and the assets theyown. A consumer's identity consists of the information that is unique tothem and that generally doesn't change, such as their name, their dateof birth, their gender, their tax identification number, and assignedidentification information such as their unique retina identity, theirfingerprint or their assigned digital bar code identification. Theiridentity also consists of generally variable information such as theirspouse and family member identities, the assets they own at anyparticular time, the details of those assets, the homes that they own,the appliances and equipment inside of those homes, and many otherthings.

On the other hand, merchants similarly manage two things: their businessidentities and capabilities, and their resources and facilities used todeliver the services they sell. The merchant's identity similarlyconsists of the information that is unique to them and generally doesn'tchange, such as their business name, the date they started operating,their location, their credit records, their tax identification numberand various other things. Their identity also similarly consists ofvariable information such as the employees that deliver services andtheir capabilities, their other business locations, their facilities,their equipment and various other things.

Within each type of code, both for consumers and merchants, there areprimary and sub-codes. Primary codes function as the identifyingproperty and sub-codes function to select options or to provide specificdetails.

At the lowest, most specific level, standard Attribute Codes are basedon nodes: the Prime Node and the Sub Node. The Prime Node represents theprime permanent identity. For an individual this is their personalidentity specifics. For merchants this is the business identityspecifics. For the Consumer Persona, examples of Prime Nodes includename, gender, driver's license number, social security number,designation of assets, and so on. Merchant Prime Nodes include businessname, business license number, business owner, designation of servicesoffered, and so on.

The Sub Node represents the specifics associated with each of the PrimeNodes. For an individual, Sub Nodes represent the attributes integratedinto their life to manage their health and personal lives and thedetails related to the assets that they own and maintain. For merchantsthis includes their services, their price list, their service personnel,their service equipment and facilities and all the details related toeach.

Consumer Persona Entity Codes

Purpose Codes address and define the specifics of a consumer (theiridentity: fixed and variable) and what assets they own and manage(homes, equipment and vehicles). Purpose Codes are organized into thethree main activities that a consumer exercises with themselves and withtheir assets: identifying them, setting preferences regarding how theymanage them and setting tasks (both recurring and incidental) for howthey are engaged, used and maintained. Objective Codes address thespecifics of what consumers want to accomplish as organized by: 1)consumer fixed identity, 2) consumer variable identity, and 3) assetidentity (which, by definition is variable since assets are generallynot owned forever).

Consumer fixed identification Object Codes relate to the type ofinformation about an individual that doesn't change, such as date ofbirth and name. Consumer variable identification Object Codes definehome and office locations, family members, preferred consumptionselections (such as the consumer's “no-show” statistics or desiredmaximum distance for appointments), medical conditions and other linkssuch as shared shopping lists between family members.

Asset variable Identification Object Codes describe assets owned, e.g.,houses, appliances, equipment, automobiles, boats, motorcycles. Theyalso are used to define variable information related to the consumerthemselves. Asset variable identification Objective Codes are used toidentify and define the variables relating to a consumer that canchange. For example, most consumers have medical insurance and canidentify the insurance carrier but that carrier can change from time totime. When changes occur, these consumer variable codes are updated bythe consumer or, if the consumers sets their preferences to allow aninsurance broker update them, they are updated by the insurance broker.Another example of a consumer variable code relates to the designationof a consumer's primary care doctor. Even though designated at aparticular time, primary care doctors can change and consequently theconsumer variable information can be changed.

Consumer fixed preference Objective Codes define a consumer's standardsfor services sought, such as feedback standards or desired preferencesfor recurring merchants. They can also describe a consumer's preferenceregarding verifying service delivery, such as by mobile device bar codescanner. Consumer variable preference Objective Codes define preferencesrelating to participating in time exchange, barter exchange or ad tagmessaging. They are also used to define a consumer's preferencesrelating to personal health and exercise preferences. Asset variablepreference Objective Codes define, for example, for an automobile owned,the maintenance preferences, such as: 1) always schedule manufacturerrecommended maintenance, 2) always schedule maintenance with aparticular merchant, or 3) don't follow the manufacturer's servicemaintenance recommendation.

Consumer fixed task Objective Codes allow consumers to select recurringobjectives for scheduling time. For example, a particular consumer canselect to schedule their recurring doctor appointments based on therecommendations of the American Medical Association (AMA). Using thesecodes, the consumer selects that option and the system accesses AMAlinks to provide the scheduling and rescheduling frequency based on theconsumer's age, medical conditions and all particulars. Because of thesystem's direct link with information sources, as this informationchanges (such as when the consumer ages or when their medical monitoringshows adverse trends), changes are made automatically.

Consumer recurring task Objective Codes provide the consumer with thetechnology to proactively achieve recurring objectives. For example, ifa consumer wants to have a weekly lunch with their son or daughter, thesystem monitors, schedules, and prescribes the lunch times in accordancewith the weekly objective. If the son or daughter wishes to have thismeeting only twice a month, they can change the directive and the systemcoordinates the change through the combined recurring task ObjectiveCodes between the consumer and their son or daughter.

Asset variable task Objective Codes provide the ability to proactivelyaddress incidental or non-recurring tasks. For example, if a consumerneeds a haircut, that task is addressed after the consumer accesses thesystem and enters the task objective.

Merchant Profile Entity Codes

For merchants, Purpose Codes are used to address and define thespecifics of the merchant and what resources they employ in the deliveryof the consumer services they sell (e.g., personnel, facilities andequipment). The merchant Purpose Codes are organized into the three mainactivities that a merchant exercises through their business to satisfycustomers: identifying them, setting preferences regarding how theyemploy and engage them, and setting tasks (both recurring andincidental) for how they are engaged on behalf of the business.

Merchant Objective Codes address the specifics of what merchants want toaccomplish as organized by: 1) merchant fixed identity, 2) merchantvariable identity, and 3) resource identity. Merchant fixedidentification Objective Codes maintain the information that doesn'tchange for a merchant (or only changes in unusual circumstances, such asbusiness renaming). For example, these Objective Codes define thebusiness name, the service sector, the date started, the taxidentification number, the business license number, the franchisor, theowner, and so forth. Merchant variable identification Objective Codesfunction to define a merchant's service offerings, price listlocation(s), GPS coordinates, hours of business, feedback ratings, andthe like. The present system uses this information when matching toachieve objectives between consumers and merchants.

Merchant resources variable identification Objective Codes are used todescribe and define the resources that the merchant has engaged in thedelivery of their services. These codes define the identity of theresource, their billing rates, their location, and the like. In the samemanner, these codes describe and define the merchant's equipment that isused for the delivery of their services and includes the sameinformation, as appropriate, as the personnel. Finally, this informationis used to describe and define the merchant's facilities that are usedto deliver their services. For example, for a health spa, this woulddefine the massage rooms.

Merchant fixed preference Objective Codes are used for merchants to setfixed or normally unchanged preferences. Examples include: 1) theacceptance of out of town patients, 2) the acceptance of mobile devicegenerated bar code check-in, 3) maximum “no-show” performance fromcustomers, and many more. These codes are used for matching objectivesbetween consumers and merchants. Merchant variable preference ObjectiveCodes are used in the system to integrate choices into the merchant'sprofile. For example, merchants use these Objective Codes to monitorpatients progress, such as a doctor who wants to be notified if ahypertensive patient's blood pressure is trending upward, or a personaltrainer who wants to monitor a client's independent workout results.

Resource variable preference Objective Codes are used to define thespecialties of service personnel and to define the capabilities ofequipment used for service (e.g., whether a particular spa technician iscapable of performing deep tissue massage.

Merchant fixed task Objective Codes are used to define the standardtasks that are performed for the services merchants deliver. Examplesinclude: allowing automatic triaging of arrivals for admission into theactive service areas, tracking appointment demand for variable pricing,tracking workflow delivery status, and so on.

Merchant recurring task Objective Codes allow merchants to set recurringtasks, such as offering appointments to out of town consumers who havealerted the system that they are seeking a service in a city that theyare visiting, comparing a merchant's performance metrics with othermerchants in the network, offering priority triaging to emergencypatients or customers, and so forth.

Merchant resource variable Objective Codes are used to set operatingstandards in the use of the resources utilized by merchants to deliverthe services they sell. For example, if a particular health spa isrequired or desires to schedule maximum work times engaged in massageservices at five hours, these codes are used to set them and themerchant's scheduling is then structured around this Objective Codedefinition.

Attribute Code Creation

Consumers create basic codes from their own information and with dataentry. For individuals, the amount of data concerning themselves, theirfamily, their assets, homes and equipment and their objectives and tasksis relatively basic. For example, most typical users will have one homeand are likely to have two cars. Their healthcare insurance programs arerelatively simple and their known maintenance needs are fairly standard.For them, the entry of their basic information will be relatively simpleand the maintenance and asset profiles that are available in the systemwill automatically and systematically create more extended maintenanceand recurring task codes for them.

Merchants, however, can have customer records that are extensive.Merchant can have price lists, service lists, resources, facilities andequipment. For customer records and history files, the system caninclude electronic/digital interface software code that will interfacebetween the merchant's legacy or existing systems to automaticallytransfer the customer information into the Merchant Profile 117. Pricelists and service offerings can require additional data entry. Thesystem includes standard or suggested preferences and tasks to simplifythe data entry process for merchants. For example, recurring tasks, suchas suggesting a service appointment to an existing customer, can beincluded as a standard feature, as will thousands of other customarybusiness practices and terms. The system includes programming logic thatcreates a library and index of customary business practices (forpreferences and tasks), and will allow merchants in similar servicesectors to use these indexed business practices collectively (andconfidentially) as part of the network and marketplace.

Attribute Code Learned Logic/Predictive Abilities

As mentioned above, the system processes Attribute Codes and codechanges and code interrelationships. For example, when a 44 year oldmale living in Washington D.C. who owns a 2006 BMW 740 I has atransmission repair at 80,000 miles on the odometer at the BMWdealership located in a city where he does not work or live, at leastfive Attribute Codes have been involved through a combination of EntityCodes, Purpose Codes, Objective Codes and Prime and Sub Nodes. Thiscombination creates a relationship of all of those elements of theAttribute Codes. The relationship is indexed in that person's AttributeCodes in their Consumer Persona 119, and in the Merchant's Profile 117,for the next service. However, the system also learns the relationshipand indexes it in the Marketplace Server 100 (the Matching Engine).Without using the consumer's or the merchant's fixed Objective Codeinformation that is confidential, this indexed Attribute Codecombination is available for the population of the system's network andmarketplace.

The system can also note that the repair was not a typical repair byreferencing the vehicle manufacturer's service recommendations andcompare this repair to other 2006 BMW 740 I's in the network todetermine the occurrence of the issue. If frequent or experiencing ahigher occurrence than other similar age cars or other years that havebeen manufactured by BMW, the system can report the occurrence rate tothe manufacturer and note the repair rate on the Attribute Code assetvariable Objective Codes of other network consumer members, where theinformation is available to those consumers when they schedule their carfor service so that it can be addressed by the merchant.

This predictive logic process can be applied to all personal, homes,vehicles and assets of individuals, but it can similarly be used bymerchants. For example, if a significant number of females 50 years oldand older who are members of the network purchase a pedicure eitherimmediately following a massage or, on the same day as the massage butat a different merchant, the system indexes this information (again,without disclosing the Consumer fixed identification Purpose andObjective Codes) and catalogs the combination of the Attribute Codes.This indexed relationship is used to suggest to network merchants whohave 50 year old and older female consumers scheduling massageappointments to offer a pedicure. If the spa does not have a pedicurefacility, this indexed information can be used to suggest businessexpansion services to the merchant based on the behaviors of the networkmembers or, more specifically, the customers of the spa.

Example Attribute Code Structure

As an example of the functionality of Attribute Codes, a hypotheticalservice request of a consumer is linked and mapped through various codesto seek what they want. In this example, a male individual on a businesstrip is seeking a haircut appointment that is within a certain distanceof his hotel. He accesses the present system to request the appointment,and the resulting sequence of code matching can include the Attributecodes shown in Table 1. The Attribute Codes can be of the fixed orvariable type, as described above:

Consumer Attribute Codes Merchant Attribute Codes Prefix Type NamePrefix Type Name 10 Consumer Consumer 20 Merchant Location (address/Identification name Identification GPS coordinates) Attribute Attribute10 Consumer Gender 200 Merchant Accept out of town IdentificationPreference customers/patients Attribute Attribute (yes/no) 300 ConsumerCurrent 400 Merchant Auto accept new Identification location Preferencecustomers/patients Attribute Attribute (yes/no) 300 Consumer Schedule400 Merchant Cumulative feedback Preference services when Preferencerating Attribute traveling Attribute (yes/no) 500 Consumer Asset Homeaddress 600 Merchant Employee specialty Attribute Resource Attribute 700Consumer Task Haircut 800 Merchant Task Haircut Attribute Attribute

Table 1

As a consumer's request is matched through the Marketplace Server 100 toresult in a confirmed appointment, the details, specifics andparticulars of that action are aligned in the consumer's calendar andthe merchant's service schedule. The results can be cataloged in theMarketplace Server 100 for future similar requests, and standard codescan be automatically generated by the Marketplace Server 100 andassigned to this particular consumer or to another consumer with asimilar request.

The terms and expressions employed herein are used as terms andexpressions of description and not of limitation, and there is nointention, in the use of such terms and expressions, of excluding anyequivalents of the features shown and described or portions thereof. Inaddition, having described certain implementations of the invention, itwill be apparent to those of ordinary skill in the art that otherimplementations incorporating the concepts disclosed herein can be usedwithout departing from the spirit and scope of the invention. Thefeatures and functions of the various implementations can be arranged invarious combinations and permutations, and all are considered to bewithin the scope of the disclosed invention. Accordingly, the describedimplementations are to be considered in all respects as illustrative andnot restrictive. The configurations, materials, and dimensions describedherein are also intended as illustrative and in no way limiting.Similarly, although physical explanations have been provided forexplanatory purposes, there is no intent to be bound by any particulartheory or mechanism, or to limit the claims in accordance therewith.

What is claimed is:
 1. A computer-implemented method comprising:obtaining an adverse report against a merchant by a customer regardingan issue with a previously scheduled appointment for a service that wasscheduled on a calendar of the customer and on a calendar of themerchant; predicting that a solution of a plurality of differentsolutions has a respective probability of resolving the issue that meetsa threshold, wherein the predicting is based on historical datacomprising attributes of different customers that were satisfied by thesolution for the issue given the service and attributes of the merchant;providing the adverse report and the predicted solution to a merchantdevice of the merchant; and within a pre-determined period of time, if aproposed resolution is not received from the merchant device, publishingthe adverse report; otherwise, if a proposed resolution is received fromthe merchant device, storing the adverse report in a non-publishablestate.
 2. The method of claim 1 wherein publishing the adverse reportcomprises: enabling the customer to modify the adverse report before theadverse report is published; receiving a modification to the adversereport from a customer device of the customer; and including themodification in the published adverse report.
 3. The method of claim 1further comprising, after storing the adverse report in thenon-publishable state, publishing the adverse report.
 4. The method ofclaim 1 further comprising enabling the customer to cancel publicationof the adverse report.
 5. The method of claim 1 wherein after receivingthe proposed resolution, the method further comprising: enabling thecustomer to provide negotiation feedback regarding the proposedresolution; receiving the negotiation feedback from a customer device ofthe customer; assigning a feedback rating to the negotiation feedback;and publishing the assigned feedback rating.
 6. The method of claim 5wherein enabling the customer to provide negotiation feedback comprisesgenerating a plurality of questions about services provided by themerchant and providing the customer device with at least one of thequestions.
 7. The method of claim 1 further comprising: monitoringpublished adverse reports against a particular merchant; and assigning arating to the particular merchant based on, at least, the publishedadverse reports.
 8. The method of claim 7 wherein assigning the ratingto the particular merchant is further based on, at least, proposedresolutions received from the merchant device.
 9. The method of claim 1wherein predicting that the solution will resolve the issue comprises:training a classifier to predict whether a given solution will resolvethe issue using historical data comprising attributes of differentcustomers that were satisfied by the solution, the service, andattributes of the merchant; and providing attributes of the customer asinput to the classifier and obtaining a prediction as output of theclassifier.
 10. A system comprising: one or more computers programmed toperform operations comprising: obtaining an adverse report against amerchant by a customer regarding an issue with a previously scheduledappointment for a service that was scheduled on a calendar of thecustomer and on a calendar of the merchant; predicting that a solutionof a plurality of different solutions has a respective probability ofresolving the issue that meets a threshold, wherein the predicting isbased on historical data comprising attributes of different customersthat were satisfied by the solution for the issue given the service andattributes of the merchant; providing the adverse report and thepredicted solution to a merchant device of the merchant; and within apre-determined period of time, if a proposed resolution is not receivedfrom the merchant device, publishing the adverse report; otherwise, if aproposed resolution is received from the merchant device, storing theadverse report in a non-publishable state.
 11. The system of claim 10wherein publishing the adverse report comprises: enabling the customerto modify the adverse report before the adverse report is published;receiving a modification to the adverse report from a customer device ofthe customer; and including the modification in the published adversereport.
 12. The system of claim 10 wherein the operations furthercomprise, after storing the adverse report in the non-publishable state,publishing the adverse report.
 13. The system of claim 10 wherein theoperations further comprise enabling the customer to cancel publicationof the adverse report.
 14. The system of claim 10 wherein afterreceiving the proposed resolution, the operations further comprise:enabling the customer to provide negotiation feedback regarding theproposed resolution; receiving the negotiation feedback from a customerdevice of the customer; assigning a feedback rating to the negotiationfeedback; and publishing the assigned feedback rating.
 15. The system ofclaim 14 wherein enabling the customer to provide negotiation feedbackcomprises generating a plurality of questions about services provided bythe merchant and providing the customer device with at least one of thequestions.
 16. The system of claim 10 wherein the operations furthercomprise: monitoring published adverse reports against a particularmerchant; and assigning a rating to the particular merchant based on, atleast, the published adverse reports.
 17. The system of claim 16 whereinassigning the rating to the particular merchant is further based on, atleast, proposed resolutions received from the merchant device.
 18. Thesystem of claim 10 wherein predicting that the solution will resolve theissue comprises: training a classifier to predict whether a givensolution will resolve the issue using historical data comprisingattributes of different customers that were satisfied by the solution,the service, and attributes of the merchant; and providing attributes ofthe customer as input to the classifier and obtaining a prediction asoutput of the classifier.
 19. An article of manufacture, comprising anon-transitory machine-readable medium storing instructions that, whenexecuted, configure one or more computers to perform operationscomprising: obtaining an adverse report against a merchant by a customerregarding an issue with a previously scheduled appointment for a servicethat was scheduled on a calendar of the customer and on a calendar ofthe merchant; predicting that a solution of a plurality of differentsolutions has a respective probability of resolving the issue that meetsa threshold, wherein the predicting is based on historical datacomprising attributes of different customers that were satisfied by thesolution for the issue given the service and attributes of the merchant;providing the adverse report and the predicted solution to a merchantdevice of the merchant; and within a pre-determined period of time, if aproposed resolution is not received from the merchant device, publishingthe adverse report; otherwise, if a proposed resolution is received fromthe merchant device, storing the adverse report in a non-publishablestate.
 20. The article of manufacture of claim 19 wherein publishing theadverse report comprises: enabling the customer to modify the adversereport before the adverse report is published; receiving a modificationto the adverse report from a customer device of the customer; andincluding the modification in the published adverse report.
 21. Thearticle of manufacture of claim 19 wherein the operations furthercomprise, after storing the adverse report in the non-publishable state,publishing the adverse report.
 22. The article of manufacture of claim19 wherein the operations further comprise enabling the customer tocancel publication of the adverse report.
 23. The article of manufactureof claim 19 wherein after receiving the proposed resolution, theoperations further comprise: enabling the customer to providenegotiation feedback regarding the proposed resolution; receiving thenegotiation feedback from a customer device of the customer; assigning afeedback rating to the negotiation feedback; and publishing the assignedfeedback rating.
 24. The article of manufacture of claim 23 whereinenabling the customer to provide negotiation feedback comprisesgenerating a plurality of questions about services provided by themerchant and providing the customer device with at least one of thequestions.
 25. The article of manufacture of claim 19 wherein theoperations further comprise: monitoring published adverse reportsagainst a particular merchant; and assigning a rating to the particularmerchant based on, at least, the published adverse reports.
 26. Thearticle of manufacture of claim 25 wherein assigning the rating to theparticular merchant is further based on, at least, proposed resolutionsreceived from the merchant device.
 27. The article of manufacture ofclaim 19 wherein predicting that the solution will resolve the issuecomprises: training a classifier to predict whether a given solutionwill resolve the issue using historical data comprising attributes ofdifferent customers that were satisfied by the solution, the service,and attributes of the merchant; and providing attributes of the customeras input to the classifier and obtaining a prediction as output of theclassifier.